date:20200520

Paolo Bonzini  writes:

> Signed-off-by: Paolo Bonzini 
> ---
>  .../testing/selftests/kvm/x86_64/state_test.c | 65 ---
>  1 file changed, 55 insertions(+), 10 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/x86_64/state_test.c 
> b/tools/testing/selftests/kvm/x86_64/state_test.c
> index 5b1a016edf55..1c5216f1ef0a 100644
> --- a/tools/testing/selftests/kvm/x86_64/state_test.c
> +++ b/tools/testing/selftests/kvm/x86_64/state_test.c
> @@ -18,10 +18,42 @@
>  #include "kvm_util.h"
>  #include "processor.h"
>  #include "vmx.h"
> +#include "svm_util.h"
>  
>  #define VCPU_ID  5
> +#define L2_GUEST_STACK_SIZE 64
> +
> +void svm_l2_guest_code(void)
> +{
> + GUEST_SYNC(4);
> +/* Exit to L1 */
> + vmcall();
> + GUEST_SYNC(6);
> + /* Done, exit to L1 and never come back.  */
> + vmcall();
> +}
> +
> +static void svm_l1_guest_code(struct svm_test_data *svm)
> +{
> +unsigned long l2_guest_stack[L2_GUEST_STACK_SIZE];
> + struct vmcb *vmcb = svm->vmcb;

Nit: indentation

> +
> + GUEST_ASSERT(svm->vmcb_gpa);
> + /* Prepare for L2 execution. */
> +generic_svm_setup(svm, svm_l2_guest_code,
> +  _guest_stack[L2_GUEST_STACK_SIZE]);
> +
> + GUEST_SYNC(3);
> + run_guest(vmcb, svm->vmcb_gpa);
> + GUEST_ASSERT(vmcb->control.exit_code == SVM_EXIT_VMMCALL);
> + GUEST_SYNC(5);
> + vmcb->save.rip += 3;
> + run_guest(vmcb, svm->vmcb_gpa);
> + GUEST_ASSERT(vmcb->control.exit_code == SVM_EXIT_VMMCALL);
> + GUEST_SYNC(7);
> +}
>  
> -void l2_guest_code(void)
> +void vmx_l2_guest_code(void)
>  {
>   GUEST_SYNC(6);
>  
> @@ -42,9 +74,8 @@ void l2_guest_code(void)
>   vmcall();
>  }
>  
> -void l1_guest_code(struct vmx_pages *vmx_pages)
> +static void vmx_l1_guest_code(struct vmx_pages *vmx_pages)
>  {
> -#define L2_GUEST_STACK_SIZE 64
>  unsigned long l2_guest_stack[L2_GUEST_STACK_SIZE];
>  
>   GUEST_ASSERT(vmx_pages->vmcs_gpa);
> @@ -56,7 +87,7 @@ void l1_guest_code(struct vmx_pages *vmx_pages)
>   GUEST_SYNC(4);
>   GUEST_ASSERT(vmptrstz() == vmx_pages->vmcs_gpa);
>  
> - prepare_vmcs(vmx_pages, l2_guest_code,
> + prepare_vmcs(vmx_pages, vmx_l2_guest_code,
>_guest_stack[L2_GUEST_STACK_SIZE]);
>  
>   GUEST_SYNC(5);
> @@ -106,20 +137,31 @@ void l1_guest_code(struct vmx_pages *vmx_pages)
>   GUEST_ASSERT(vmresume());
>  }
>  
> -void guest_code(struct vmx_pages *vmx_pages)
> +static u32 cpuid_ecx(u32 eax)
> +{
> + u32 result;
> + asm volatile("cpuid" : "=c" (result) : "a" (eax));

Nit: doesn't cpuid clobber ebx/edx too? (and ecx also works as
input). I'd suggest we write correct implementation and put it to
the library (or find a way to use native_cpuid() from
arch/x86/include/asm/processor.h)

> + return result;
> +}
> +
> +static void __attribute__((__flatten__)) guest_code(void *arg)
>  {
>   GUEST_SYNC(1);
>   GUEST_SYNC(2);
>  
> - if (vmx_pages)
> - l1_guest_code(vmx_pages);
> + if (arg) {
> + if (cpuid_ecx(0x8001) & CPUID_SVM)
> + svm_l1_guest_code(arg);
> + else
> + vmx_l1_guest_code(arg);
> + }
>  
>   GUEST_DONE();
>  }
>  
>  int main(int argc, char *argv[])
>  {
> - vm_vaddr_t vmx_pages_gva = 0;
> + vm_vaddr_t nested_gva = 0;
>  
>   struct kvm_regs regs1, regs2;
>   struct kvm_vm *vm;
> @@ -136,8 +178,11 @@ int main(int argc, char *argv[])
>   vcpu_regs_get(vm, VCPU_ID, );
>  
>   if (kvm_check_cap(KVM_CAP_NESTED_STATE)) {
> - vcpu_alloc_vmx(vm, _pages_gva);
> - vcpu_args_set(vm, VCPU_ID, 1, vmx_pages_gva);
> + if (kvm_get_supported_cpuid_entry(0x8001)->ecx & CPUID_SVM)
> + vcpu_alloc_svm(vm, _gva);
> + else
> + vcpu_alloc_vmx(vm, _gva);
> + vcpu_args_set(vm, VCPU_ID, 1, nested_gva);
>   } else {
>   pr_info("will skip nested state checks\n");
>   vcpu_args_set(vm, VCPU_ID, 1, 0);

With two nitpicks above,

Reviewed-by: Vitaly Kuznetsov 

-- 
Vitaly

Re: [PATCHv3 2/5] Input: EXC3000: switch to i2c's probe_new API

2020-05-20 Thread Enric Balletbo i Serra

Hi Sebastian,

On 20/5/20 17:39, Sebastian Reichel wrote:
> Switch to the "new" I2C probe API.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  drivers/input/touchscreen/exc3000.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/exc3000.c 
> b/drivers/input/touchscreen/exc3000.c
> index e007e2e8f626..555a14305cd4 100644
> --- a/drivers/input/touchscreen/exc3000.c
> +++ b/drivers/input/touchscreen/exc3000.c
> @@ -145,8 +145,7 @@ static irqreturn_t exc3000_interrupt(int irq, void 
> *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> -static int exc3000_probe(struct i2c_client *client,
> -  const struct i2c_device_id *id)
> +static int exc3000_probe(struct i2c_client *client)
>  {
>   struct exc3000_data *data;
>   struct input_dev *input;
> @@ -210,7 +209,7 @@ static struct i2c_driver exc3000_driver = {
>   .of_match_table = of_match_ptr(exc3000_of_match),
>   },
>   .id_table   = exc3000_id,
> - .probe  = exc3000_probe,
> + .probe_new  = exc3000_probe,
>  };
>  
>  module_i2c_driver(exc3000_driver);
>

Re: [RFC PATCH] tick/sched: update full_nohz status after SCHED dep is cleared

2020-05-20 Thread Juri Lelli

On 20/05/20 18:24, Frederic Weisbecker wrote:
> Hi Juri,
> 
> On Wed, May 20, 2020 at 04:04:02PM +0200, Juri Lelli wrote:
> > After tasks enter or leave a runqueue (wakeup/block) SCHED full_nohz
> > dependency is checked (via sched_update_tick_dependency()). In case tick
> > can be stopped on a CPU (see sched_can_stop_tick() for details), SCHED
> > dependency for such CPU is cleared. However, this new information is not
> > used right away to actually stop the tick.
> > 
> > In CONFIG_PREEMPT systems booted with threadirqs option, sched clock
> > tick is serviced by an actual task (ksoftirqd corresponding to the CPU
> > where tick timer fired).
> 
> I must confess I haven't tested threaded IRQs but I was
> pretty sure that the timer tick is always serviced on hardirq.
> 
> Now the timer list callbacks are executed on softirqs. So if the
> tick itself, executed on hardirq, sees pending timers, it raise
> the softirq which wakes up ksoftirqd on forced irq thread mode
> while calling irq_exit(). Then tick_nohz_irq_exit() sees ksoftirqd
> and the current task on the runqueue, which together can indeed prevent
> from turning off the tick. But then the root cause is pending timer
> list callbacks.
> 
> > So, in case a CPU was running a single task,
> > servicing the timer involves exiting full nozh mode. Problem at this
> > point is that we might lose chances to enter back into full nozh mode,
> > since info about ksoftirqd thread going back to sleep is not used (as
> > mentioned above).
> 
> It should enter into nohz_full mode in the next tick, which is usually
> a reasonable delay. If you need guarantee that the tick is stopped before
> resuming userspace, you need a stronger machinery such as the task isolation
> patchset.
> 
> Let's have a look at the trace below:
> 
> > ksoftirqd/19-125   [019]   170.700754: softirq_entry:vec=1 
> > [action=TIMER]
> > ksoftirqd/19-125   [019]   170.700755: softirq_exit: vec=1 
> > [action=TIMER]
> > ksoftirqd/19-125   [019]   170.700756: softirq_entry:vec=7 
> > [action=SCHED]
> > ksoftirqd/19-125   [019]   170.700757: softirq_exit: vec=7 
> > [action=SCHED]
> > ksoftirqd/19-125   [019]   170.700759: sched_switch: 
> > ksoftirqd/19:125 [120] S ==> sysjitter:2459 [120]
> >sysjitter-2459  [019]   170.701740: local_timer_entry:vector=236
> >sysjitter-2459  [019]   170.701742: softirq_raise:vec=1 
> > [action=TIMER]
> 
> See here the tick sees pending timer callbacks so it raises the timer softirq.
> 
> >sysjitter-2459  [019]   170.701743: softirq_raise:vec=7 
> > [action=SCHED]
> 
> Oh and the scheduler tick activates the scheduler softirq as well.
> 
> >sysjitter-2459  [019]   170.701744: local_timer_exit: vector=236
> >sysjitter-2459  [019]   170.701747: sched_wakeup: 
> > ksoftirqd/19:125 [120] success=1 CPU:019
> >sysjitter-2459  [019]   170.701748: tick_stop:success=0 
> > dependency=SCHED
> >sysjitter-2459  [019]   170.701749: irq_work_entry:   vector=246
> >sysjitter-2459  [019]   170.701750: irq_work_exit:vector=246
> >sysjitter-2459  [019]   170.701751: tick_stop:success=0 
> > dependency=SCHED
> >sysjitter-2459  [019]   170.701753: sched_switch: sysjitter:2459 
> > [120] R ==> ksoftirqd/19:125 [120]
> > ksoftirqd/19-125   [019]   170.701754: softirq_entry:vec=1 
> > [action=TIMER]
> > ksoftirqd/19-125   [019]   170.701756: softirq_exit: vec=1 
> > [action=TIMER]
> > ksoftirqd/19-125   [019]   170.701756: softirq_entry:vec=7 
> > [action=SCHED]
> > ksoftirqd/19-125   [019]   170.701758: softirq_exit: vec=7 
> > [action=SCHED]
> > ksoftirqd/19-125   [019]   170.701759: sched_switch: 
> > ksoftirqd/19:125 [120] S ==> sysjitter:2459 [120]
> >sysjitter-2459  [019]   170.702740: local_timer_entry:vector=236
> >sysjitter-2459  [019]   170.702742: softirq_raise:vec=1 
> > [action=TIMER]
> 
> A new tick but we still have pending timer callback so we'll need to wakeup 
> ksoftirqd
> again.
> 
> I think you should trace timers and check which one is concerned here.

Hummm, so I enabled 'timer:*', anything else you think I should be
looking at?

...
ksoftirqd/13-117   [013]   148.265945: softirq_entry:vec=1 
[action=TIMER]
ksoftirqd/13-117   [013]   148.265947: softirq_exit: vec=1 
[action=TIMER]
ksoftirqd/13-117   [013]   148.265948: softirq_entry:vec=7 
[action=SCHED]
ksoftirqd/13-117   [013]   148.265950: softirq_exit: vec=7 
[action=SCHED]
ksoftirqd/13-117   [013]   148.265952: sched_switch: ksoftirqd/13:117 
[120] S ==> sysjitter:2536 [120]
   sysjitter-2536  [013]   148.266912: local_timer_entry:vector=236
   sysjitter-2536  [013]   148.266914: hrtimer_cancel:   
hrtimer=0x9807df91bee0
   sysjitter-2536  [013]   148.266916: hrtimer_expire_entry: 
hrtimer=0x9807df91bee0 now=148249107837

[PATCH v1 2/3] irqdomain: Get rid of special treatment for ACPI in __irq_domain_add()

After change __irq_domain_add() to cooperate better with fwnodes
we don't need to have special treatment for ACPI case.

Get rid of the special treatment for ACPI.

Signed-off-by: Andy Shevchenko 
---
 kernel/irq/irqdomain.c | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index d59a4224f920..c6204bc606a2 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -161,22 +161,7 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle 
*fwnode, int size,
domain->name = fwid->name;
break;
}
-#ifdef CONFIG_ACPI
-   } else if (is_acpi_device_node(fwnode)) {
-   struct acpi_buffer buf = {
-   .length = ACPI_ALLOCATE_BUFFER,
-   };
-   acpi_handle handle;
-
-   handle = acpi_device_handle(to_acpi_device_node(fwnode));
-   if (acpi_get_name(handle, ACPI_FULL_PATHNAME, ) == AE_OK) {
-   domain->name = buf.pointer;
-   domain->flags |= IRQ_DOMAIN_NAME_ALLOCATED;
-   }
-
-   domain->fwnode = fwnode;
-#endif
-   } else if (is_of_node(fwnode)) {
+   } else if (is_of_node(fwnode) || is_acpi_device_node(fwnode)) {
char *name;
 
/*
-- 
2.26.2

Re: [PATCH v3 1/7] bus: mhi: core: Abort suspends due to outgoing pending packets

2020-05-20 Thread Jeffrey Hugo


On 5/18/2020 2:03 PM, Bhaumik Bhatt wrote:

Add the missing check to abort suspends if a client has pending outgoing
packets to send to the device. This allows better utilization of the MHI
bus wherein clients on the host are not left waiting for longer suspend
or resume cycles to finish for data transfers.

Signed-off-by: Bhaumik Bhatt 
---


Reviewed-by: Jeffrey Hugo 

--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v1 3/3] irqdomain: Allow software node to be correct one for IRQ domain

In some cases we might need to have an IRQ domain created out of software node.
One of such cases is DesignWare GPIO driver when it's instantiated from
half-baked ACPI table (alas, we can't fix it for devices which are few years
on market) and thus using software nodes to quirk this up. But the driver
is using IRQ domains based on per GPIO port firmware nodes, which are in
the above case software ones. This brings a warning message to be printed

  [   73.957183] irq: Invalid fwnode type for irqdomain

and creates an unknown IRQ domain.

When we allow software node to be correct one for IRQ domain we will
get rid of the warning message and nice domain name at the same time:

  % ls -1 /sys/kernel/debug/irq/domains/
  ...
  intel-quark-dw-apb-gpio:portA

Signed-off-by: Andy Shevchenko 
---
 kernel/irq/irqdomain.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index c6204bc606a2..e4ebc5398ef5 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -161,7 +161,8 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle 
*fwnode, int size,
domain->name = fwid->name;
break;
}
-   } else if (is_of_node(fwnode) || is_acpi_device_node(fwnode)) {
+   } else if (is_of_node(fwnode) || is_acpi_device_node(fwnode) ||
+  is_software_node(fwnode)) {
char *name;
 
/*
-- 
2.26.2

[PATCH v1 1/3] irqdomain: Make __irq_domain_add() less OF-dependent

__irq_domain_add() in some places relies on the fact that fwnode
can be only type of OF. This prevents refactoring of the code
to support other types of fwnode. Make it less OF-dependent
by switching to use fwnode directly where it makes sense.

Signed-off-by: Andy Shevchenko 
---
 kernel/irq/irqdomain.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 35b8d97c3a1d..d59a4224f920 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -132,14 +132,13 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle 
*fwnode, int size,
const struct irq_domain_ops *ops,
void *host_data)
 {
-   struct device_node *of_node = to_of_node(fwnode);
struct irqchip_fwid *fwid;
struct irq_domain *domain;
 
static atomic_t unknown_domains;
 
domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) * size),
- GFP_KERNEL, of_node_to_nid(of_node));
+ GFP_KERNEL, of_node_to_nid(to_of_node(fwnode)));
if (!domain)
return NULL;
 
@@ -177,15 +176,15 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle 
*fwnode, int size,
 
domain->fwnode = fwnode;
 #endif
-   } else if (of_node) {
+   } else if (is_of_node(fwnode)) {
char *name;
 
/*
-* DT paths contain '/', which debugfs is legitimately
+* fwnode paths contain '/', which debugfs is legitimately
 * unhappy about. Replace them with ':', which does
 * the trick and is not as offensive as '\'...
 */
-   name = kasprintf(GFP_KERNEL, "%pOF", of_node);
+   name = kasprintf(GFP_KERNEL, "%pfw", fwnode);
if (!name) {
kfree(domain);
return NULL;
@@ -210,7 +209,7 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle 
*fwnode, int size,
domain->flags |= IRQ_DOMAIN_NAME_ALLOCATED;
}
 
-   of_node_get(of_node);
+   fwnode_handle_get(fwnode);
 
/* Fill structure */
INIT_RADIX_TREE(>revmap_tree, GFP_KERNEL);
@@ -259,7 +258,7 @@ void irq_domain_remove(struct irq_domain *domain)
 
pr_debug("Removed domain %s\n", domain->name);
 
-   of_node_put(irq_domain_get_of_node(domain));
+   fwnode_handle_put(domain->fwnode);
if (domain->flags & IRQ_DOMAIN_NAME_ALLOCATED)
kfree(domain->name);
kfree(domain);
-- 
2.26.2

Re: [PATCH] hwrng: ks-sa - fix runtime pm imbalance on error

2020-05-20 Thread st...@rowland.harvard.edu

On Wed, May 20, 2020 at 03:42:17PM +, Sverdlin, Alexander (Nokia - DE/Ulm) 
wrote:
> Hello Dinghao,
> 
> On Wed, 2020-05-20 at 21:29 +0800, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > the call returns an error code. Thus a pairing decrement is needed
> > on the error handling path to keep the counter balanced.
> 
> I believe, this is the wrong place for such kind of fix.
> pm_runtime_get_sync() has obviously a broken semantics with regards to
> your observation but no other driver does what you propose.

Look again.  For example, see what usb_autoresume_device() in 
drivers/usb/core/driver.c does.

You really shouldn't make generalizations such as "no other driver does 
..." unless you have read the code for every driver in the kernel.

Alan Stern

Re: [PATCH] w1_therm: Free the correct variable

2020-05-20 Thread Akira shimahara

Hi,

Le mercredi 20 mai 2020 à 15:00 +0300, Dan Carpenter a écrit :
> The problem is that we change "p_args" to point to the middle of the
> string so when we free it at the end of the function it's not freeing
> the same pointer that we originally allocated.
> 
> Fixes: e2c94d6f5720 ("w1_therm: adding alarm sysfs entry")
> Signed-off-by: Dan Carpenter 
> ---
> From static analysis.  I guess it must not cause too much of a problem
> at run time?
> 
>  drivers/w1/slaves/w1_therm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
> index cc4b88056b33..a6c85e486671 100644
> --- a/drivers/w1/slaves/w1_therm.c
> +++ b/drivers/w1/slaves/w1_therm.c
> @@ -1526,8 +1526,9 @@ static ssize_t alarms_store(struct device *device,
>   int temp, ret = -EINVAL;
>   char *token = NULL;
>   s8 tl, th, tt;  /* 1 byte per value + temp ring order */
> - char *p_args = kmalloc(size, GFP_KERNEL);
> + char *p_args, *orig;
>  
> + p_args = orig = kmalloc(size, GFP_KERNEL);
>   /* Safe string copys as buf is const */
>   if (!p_args) {
>   dev_warn(device,
> @@ -1611,7 +1612,7 @@ static ssize_t alarms_store(struct device *device,
>  
>  free_m:
>   /* free allocated memory */
> - kfree(p_args);
> + kfree(orig);
>  
>   return size;
>  }

I tested it on several devices to be safe, no issue at runtime.
Sorry for the mistake and thanks for the fix.

Akira Shimahara

Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869

2020-05-20 Thread Andrew Lunn

> I am interested in knowing where that is documented.  I want to RTM I
> grepped for a few different words but came up empty

Hi Dan

It probably is not well documented, but one example would be

Documentation/devicetree/bindings/net/ethernet-controller.yaml

says:

  # RX and TX delays are added by the MAC when required
  - rgmii

  # RGMII with internal RX and TX delays provided by the PHY,
  # the MAC should not add the RX or TX delays in this case
  - rgmii-id

  # RGMII with internal RX delay provided by the PHY, the MAC
  # should not add an RX delay in this case
  - rgmii-rxid

  # RGMII with internal TX delay provided by the PHY, the MAC
  # should not add an TX delay in this case

  Andrew

Re: [PATCH] PCI: tegra: fix runtime pm imbalance on error

2020-05-20 Thread Bjorn Helgaas

On Wed, May 20, 2020 at 04:40:12PM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
> 
> Also This driver forgets to call pm_runtime_disable() when
> pm_runtime_get_sync() returns an error code.

  Also, call pm_runtime_disable() when pm_runtime_get_sync() returns
  an error code.

> Signed-off-by: Dinghao Liu 
> ---
>  drivers/pci/controller/pci-tegra.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/pci-tegra.c 
> b/drivers/pci/controller/pci-tegra.c
> index 3e64ba6a36a8..00236dd65b5b 100644
> --- a/drivers/pci/controller/pci-tegra.c
> +++ b/drivers/pci/controller/pci-tegra.c
> @@ -2712,7 +2712,7 @@ static int tegra_pcie_probe(struct platform_device 
> *pdev)
>   err = pm_runtime_get_sync(pcie->dev);
>   if (err < 0) {
>   dev_err(dev, "fail to enable pcie controller: %d\n", err);
> - goto teardown_msi;
> + goto pm_runtime_put;
>   }
>  
>   host->busnr = bus->start;
> @@ -2746,7 +2746,6 @@ static int tegra_pcie_probe(struct platform_device 
> *pdev)
>  pm_runtime_put:
>   pm_runtime_put_sync(pcie->dev);
>   pm_runtime_disable(pcie->dev);
> -teardown_msi:
>   tegra_pcie_msi_teardown(pcie);
>  put_resources:
>   tegra_pcie_put_resources(pcie);
> -- 
> 2.17.1
>

Re: [PATCH v1] Revert "software node: Simplify software_node_release() function"

On Wed, May 20, 2020 at 05:02:27PM +0200, Petr Mladek wrote:
> On Thu 2020-02-27 16:00:01, Brendan Higgins wrote:

> I have found similar report from a test robot, see
> https://lore.kernel.org/lkml/20200303002816.GW6548@shao2-debian/
> 
> 
> I was staring into it for a while and do not understand it. The revert
> makes sense. I wonder if it somehow changes the order in which
> the release methods are called.
> 
> Anyway, reverting the revert makes test_printf working.

There is a proper fix IIRC from Heikki in driver core (no link at hand, sorry).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/3] objtool: Enable compilation of objtool for all architectures

2020-05-20 Thread Matt Helsley

On Wed, May 20, 2020 at 09:31:46AM +0100, Julien Thierry wrote:
> 
> 
> On 5/19/20 9:55 PM, Matt Helsley wrote:
> > objtool currently only compiles for x86 architectures. This is
> > fine as it presently does not support tooling for other
> > architectures. However, we would like to be able to convert other
> > kernel tools to run as objtool sub commands because they too
> > process ELF object files. This will allow us to convert tools
> > such as recordmcount to use objtool's ELF code.
> > 
> > Since much of recordmcount's ELF code is copy-paste code to/from
> > a variety of other kernel tools (look at modpost for example) this
> > means that if we can convert recordmcount we can convert more.
> > 
> > We define "missing" weak definitions for subcommand entry functions
> > and other weak definitions for shared functions critical to
> > building existing subcommands. These return 127 when the command is
> > missing which signify tools that do not exist on all architectures.
> > In this case the "check" and "orc" tools do not exist on all
> > architectures so we only add them for x86. Future changes adding
> > support for "check", to arm64 for example, can then modify the
> > SUBCMD_CHECK variable when building for arm64.
> > 
> > objtool is not currently wired in to KConfig to be built for other
> > architectures because it's not needed for those architectures and
> > there are no commands it supports other than those for x86. As more
> > command support is enabled on various architectures the necessary
> > KConfig changes can be made (e.g. adding "STACK_VALIDATION") to
> > trigger building objtool.
> > 
> > Signed-off-by: Matt Helsley 
> > Cc: Julien Thierry 
> > ---
> >   tools/objtool/Build   | 13 +
> >   tools/objtool/Makefile| 11 ++-
> >   tools/objtool/arch.h  |  4 +++-
> >   tools/objtool/builtin-check.c |  2 +-
> >   tools/objtool/builtin-orc.c   |  3 +--
> >   tools/objtool/check.c |  4 ++--
> >   tools/objtool/check.h |  4 
> >   tools/objtool/objtool.h   | 14 ++
> >   tools/objtool/orc.h   | 18 --
> >   tools/objtool/orc_dump.c  |  3 ++-
> >   tools/objtool/orc_gen.c   |  1 -
> >   tools/objtool/weak.c  | 35 +++
> >   12 files changed, 77 insertions(+), 35 deletions(-)
> >   delete mode 100644 tools/objtool/orc.h
> >   create mode 100644 tools/objtool/weak.c
> > 
> > diff --git a/tools/objtool/Build b/tools/objtool/Build
> > index 66f44f5cd2a6..b7222d5cc7bc 100644
> > --- a/tools/objtool/Build
> > +++ b/tools/objtool/Build
> > @@ -1,11 +1,16 @@
> >   objtool-y += arch/$(SRCARCH)/
> > +
> > +objtool-y += weak.o
> > +
> > +objtool-$(SUBCMD_CHECK) += check.o
> > +objtool-$(SUBCMD_CHECK) += special.o
> > +objtool-$(SUBCMD_ORC) += check.o
> > +objtool-$(SUBCMD_ORC) += orc_gen.o
> > +objtool-$(SUBCMD_ORC) += orc_dump.o
> > +
> >   objtool-y += builtin-check.o
> >   objtool-y += builtin-orc.o
> > -objtool-y += check.o
> > -objtool-y += orc_gen.o
> > -objtool-y += orc_dump.o
> >   objtool-y += elf.o
> > -objtool-y += special.o
> >   objtool-y += objtool.o
> >   objtool-y += libstring.o
> > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> > index 6b91388aecbb..12686e2f1a56 100644
> > --- a/tools/objtool/Makefile
> > +++ b/tools/objtool/Makefile
> > @@ -46,7 +46,16 @@ elfshdr := $(shell echo '$(pound)include ' | 
> > $(CC) $(CFLAGS) -x c -E -
> >   CFLAGS += $(if $(elfshdr),,-DLIBELF_USE_DEPRECATED)
> >   AWK = awk
> > -export srctree OUTPUT CFLAGS SRCARCH AWK
> > +
> > +SUBCMD_CHECK := n
> > +SUBCMD_ORC := n
> > +
> > +ifeq ($(SRCARCH),x86)
> > +   SUBCMD_CHECK := y
> > +   SUBCMD_ORC := y
> > +endif
> > +
> > +export srctree OUTPUT CFLAGS SRCARCH AWK SUBCMD_CHECK SUBCMD_ORC
> 
> Nit: I was thinking, since the list of SUBCMD_* is only going to grow
> maybe it would be nicer to have a single export line for the SUBCMD_*
> variables and leave the export line of [srctree..AWK] untouched.

That's a really good idea actually. Glad to see Josh included it in the
changed patch.

> 
> Just a suggestion, and only in case you respin this taking into account
> Josh's comment.
> 
> Otherwise things look good to me.

Thanks for all the reviews and good ideas!

Cheers,
-Matt Helsley

Re: kernel BUG at fs/inode.c:531!

2020-05-20 Thread Randy Dunlap

[adding Cc:s]

Kernel is 5.7.0-rc6.20200519.


On 5/20/20 5:57 AM, nirinA raseliarison wrote:
> hello ,
> 
> i repeatedly hit this bug since gcc-10.1.0:
> 
> May 20 05:06:25 supernova kernel: [16312.604136] [ cut
> here ]
> May 20 05:06:25 supernova kernel: [16312.604139] kernel BUG at fs/inode.c:531!
> May 20 05:06:25 supernova kernel: [16312.604145] invalid opcode: 
> [#1] SMP PTI
> May 20 05:06:25 supernova kernel: [16312.604148] CPU: 1 PID: 149 Comm:
> kswapd0 Not tainted 5.7.0-rc6.20200519 #1
> May 20 05:06:25 supernova kernel: [16312.604150] Hardware name: To be
> filled by O.E.M. To be filled by O.E.M./ONDA H61V Ver:4.01, BIOS 4.6.5
> 01/07/2013
> May 20 05:06:25 supernova kernel: [16312.604155] RIP: 
> 0010:clear_inode+0x75/0x80
> May 20 05:06:25 supernova kernel: [16312.604157] Code: a8 20 74 2a a8
> 40 75 28 48 8b 83 28 01 00 00 48 8d 93 28 01 00 00 48 39 c2 75 17 48
> c7 83 98 00 00 00 60 00 00 00 5b c3 0f 0b <0f> 0b 0f 0b 0f 0b 0f 0b 0f
> 0b 90 0f 1f 44 00 00 53 ba 48 02 00 00
> May 20 05:06:25 supernova kernel: [16312.604158] RSP:
> :c948fb50 EFLAGS: 00010006
> May 20 05:06:25 supernova kernel: [16312.604160] RAX: 
> RBX: 88808c5f9e38 RCX: 
> May 20 05:06:25 supernova kernel: [16312.604161] RDX: 0001
> RSI:  RDI: 88808c5f9fb8
> May 20 05:06:25 supernova kernel: [16312.604162] RBP: 88808c5f9e38
> R08:  R09: c948fcd8
> May 20 05:06:25 supernova kernel: [16312.604163] R10: 
> R11: 0520 R12: 88808c5f9fb0
> May 20 05:06:25 supernova kernel: [16312.604164] R13: 88820f14d000
> R14: 88820f14d070 R15: 0122
> May 20 05:06:25 supernova kernel: [16312.604166] FS:
> () GS:88821770()
> knlGS:
> May 20 05:06:25 supernova kernel: [16312.604167] CS:  0010 DS: 
> ES:  CR0: 80050033
> May 20 05:06:25 supernova kernel: [16312.604168] CR2: 7f7849e58000
> CR3: 1e676006 CR4: 001606e0
> May 20 05:06:25 supernova kernel: [16312.604169] Call Trace:
> May 20 05:06:25 supernova kernel: [16312.604174]  ext4_clear_inode+0x16/0x80
> May 20 05:06:25 supernova kernel: [16312.604177]  ext4_evict_inode+0x58/0x4c0
> May 20 05:06:25 supernova kernel: [16312.604180]  evict+0xbf/0x180
> May 20 05:06:25 supernova kernel: [16312.604183]  prune_icache_sb+0x7e/0xb0
> May 20 05:06:25 supernova kernel: [16312.604186]  super_cache_scan+0x161/0x1e0
> May 20 05:06:25 supernova kernel: [16312.604189]  do_shrink_slab+0x146/0x290
> May 20 05:06:25 supernova kernel: [16312.604191]  shrink_slab+0xac/0x2a0
> May 20 05:06:25 supernova kernel: [16312.604194]  ? __switch_to_asm+0x40/0x70
> May 20 05:06:25 supernova kernel: [16312.604196]  shrink_node+0x16f/0x660
> May 20 05:06:25 supernova kernel: [16312.604199]  balance_pgdat+0x2cf/0x5b0
> May 20 05:06:25 supernova kernel: [16312.604201]  kswapd+0x1dc/0x3a0
> May 20 05:06:25 supernova kernel: [16312.604204]  ? __schedule+0x217/0x710
> May 20 05:06:25 supernova kernel: [16312.604206]  ? wait_woken+0x80/0x80
> May 20 05:06:25 supernova kernel: [16312.604208]  ? balance_pgdat+0x5b0/0x5b0
> May 20 05:06:25 supernova kernel: [16312.604210]  kthread+0x118/0x130
> May 20 05:06:25 supernova kernel: [16312.604212]  ?
> kthread_create_worker_on_cpu+0x70/0x70
> May 20 05:06:25 supernova kernel: [16312.604214]  ret_from_fork+0x35/0x40
> May 20 05:06:25 supernova kernel: [16312.604215] Modules linked in:
> nct6775 hwmon_vid rfkill ipv6 nf_defrag_ipv6 snd_pcm_oss snd_mixer_oss
> fuse hid_generic usbhid hid i2c_dev snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_codec_generic coretemp hwmon
> x86_pkg_temp_thermal intel_powerclamp i915 kvm_intel kvm irqbypass
> evdev crc32_pclmul serio_raw r8169 drm_kms_helper snd_hda_intel
> snd_intel_dspcfg realtek snd_hda_codec libphy snd_hwdep syscopyarea
> sysfillrect sysimgblt snd_hda_core fan fb_sys_fops thermal snd_pcm drm
> 8250 mei_me snd_timer drm_panel_orientation_quirks 8250_base
> serial_core intel_gtt video snd ehci_pci lpc_ich ehci_hcd mei agpgart
> soundcore button i2c_algo_bit i2c_i801 loop
> May 20 05:06:25 supernova kernel: [16312.604237] ---[ end trace
> 6d45434b7eb1e097 ]---
> May 20 05:06:25 supernova kernel: [16312.604240] RIP: 
> 0010:clear_inode+0x75/0x80
> May 20 05:06:25 supernova kernel: [16312.604241] Code: a8 20 74 2a a8
> 40 75 28 48 8b 83 28 01 00 00 48 8d 93 28 01 00 00 48 39 c2 75 17 48
> c7 83 98 00 00 00 60 00 00 00 5b c3 0f 0b <0f> 0b 0f 0b 0f 0b 0f 0b 0f
> 0b 90 0f 1f 44 00 00 53 ba 48 02 00 00
> May 20 05:06:25 supernova kernel: [16312.604242] RSP:
> :c948fb50 EFLAGS: 00010006
> May 20 05:06:25 supernova kernel: [16312.604244] RAX: 
> RBX: 88808c5f9e38 RCX: 
> May 20 05:06:25 supernova kernel: [16312.604245] RDX: 0001
> RSI:  RDI: 88808c5f9fb8
> May 20 05:06:25 supernova kernel:

Re: XHCI vs PCM2903B/PCM2904 part 2

2020-05-20 Thread Alan Stern

On Wed, May 20, 2020 at 07:26:57AM -0400, Rik van Riel wrote:
> After a few more weeks of digging, I have come to the tentative
> conclusion that either the XHCI driver, or the USB sound driver,
> or both, fail to handle USB errors correctly.
> 
> I have some questions at the bottom, after a (brief-ish) explanation
> of exactly what seems to go wrong.
> 
> TL;DR: arecord from a misbehaving device can hang forever
> after a USB error, due to poll on /dev/snd/timer never returning.
> 
> The details: under some mysterious circumstances, the PCM290x
> family sound chips can send more data than expected during an
> isochronous transfer, leading to a babble error. Those

Do these chips connect as USB-3 devices or as USB-2?  (I wouldn't expect 
an audio device to use USB-3; it shouldn't need the higher bandwidth.)

> circumstances seem to in part depend on the USB host controller
> and/or the electrical environment, since the chips work just
> fine for most people.
> 
> Receiving data past the end of the isochronous transfer window
> scheduled for a device results in the XHCI controller throwing
> a babble error, which moves the endpoint into halted state.
> 
> This is followed by the host controller software sending a
> reset endpoint command, and moving the endpoint into stopped
> state, as specified on pages 164-165 of the XHCI specification.

In general, errors such as babble are not supposed to stop isochronous 
endpoints.

> However, the USB sound driver seems to have no idea that this
> error happened. The function retire_capture_urb looks at the
> status of each isochronous frame, but seems to be under the
> assumption that the sound device just keeps on running.

This is appropriate, for the reason mentioned above.

> The function snd_complete_urb seems to only detect that the
> device is not running if usb_submit_urb returns a failure.
> 
> err = usb_submit_urb(urb, GFP_ATOMIC);
> if (err == 0)
> return;
> 
> usb_audio_err(ep->chip, "cannot submit urb (err = %d)\n", err);
> 
> if (ep->data_subs && ep->data_subs->pcm_substream) {
> substream = ep->data_subs->pcm_substream;
> snd_pcm_stop_xrun(substream);
> }
> 
> However, the XHCI driver will happily submit an URB to a
> stopped device.

Do you mean "stopped device" or "stopped endpoint"?

>  Looking at the call trace usb_submit_urb ->
> xhci_urb_enqueue -> xhci_queue_isoc_tx_prepare -> prepare_ring,
> you can see this code:
> 
> /* Make sure the endpoint has been added to xHC schedule */
> switch (ep_state) {
> ...
> case EP_STATE_HALTED:
> xhci_dbg(xhci, "WARN halted endpoint, queueing URB 
> anyway.\n");
> case EP_STATE_STOPPED:
> case EP_STATE_RUNNING:
> break;
> 
> This leads me to a few questions:
> - should retire_capture_urb call snd_pcm_stop_xrun,
>   or another function like it, if it sees certain
>   errors in the iso frame in the URB?

No.  Isochronous endpoints are expected to encounter errors from time to 
time; that is the nature of isochronous communications.  You're supposed 
to ignore the errors (skip over any bad data) and keep going.

> - should snd_complete_urb do something with these
>   errors, too, in case they happen on the sync frames
>   and not the data frames?
> - does the XHCI code need to ring the doorbell when
>   submitting an URB to a stopped device, or is it
>   always up to the higher-level driver to fully reset
>   the device before it can do anything useful?

In this case it is not up to the higher-level driver.

> - if a device in stopped state does not do anything
>   useful, should usb_submit_urb return an error?

The notion of "stopped state" is not part of USB-2.  As a result, it 
should be handled entirely within the xhci-hcd driver.

(A non-isochronous endpoint can be in the "halted" state.  But obviously 
this isn't what you're talking about.)

> - how should the USB sound driver recover from these
>   occasional and/or one-off errors? stop the sound
>   stream, or try to reinitialize the device and start
>   recording again?

As far as I know, it should do its best to continue (perhaps fill in 
missing data with zeros).

Alan Stern

> I am willing to write patches and can test with my
> setup, but both the sound code and the USB code are
> new to me so I would like to know what direction I
> should go in :)

Re: [PATCH 3/3] objtool: Enable compilation of objtool for all architectures

2020-05-20 Thread Matt Helsley

On Wed, May 20, 2020 at 09:16:04AM -0500, Josh Poimboeuf wrote:
> On Tue, May 19, 2020 at 02:46:37PM -0700, Matt Helsley wrote:
> > On Tue, May 19, 2020 at 04:18:29PM -0500, Josh Poimboeuf wrote:
> > > On Tue, May 19, 2020 at 01:55:33PM -0700, Matt Helsley wrote:
> > > > +const char __attribute__ ((weak)) *objname;
> > > > +
> > > > +int missing_check(const char *_objname, bool orc)
> > > > +{
> > > > +   return 127;
> > > > +}
> > > > +
> > > > +int __attribute__ ((weak, alias("missing_check"))) check(const char 
> > > > *_objname, bool orc);
> > > > +
> > > > +int missing_orc_dump(const char *_objname)
> > > > +{
> > > > +   return 127;

Just a note in case anyone reviews this thread later:

I chose to return 127 rather than an errno value because it eventually
gets set as the exit status and bash, at least, uses 127 for "function not
defined". ENOSYS makes more sense internally and does "fit" as an exit
status so changing to ENOSYS does make more sense.

> > > > +}
> > > > +
> > > > +int __attribute__ ((weak, alias("missing_orc_dump"))) orc_dump(const 
> > > > char *_objname);
> > > > +
> > > > +int __attribute__ ((weak)) create_orc(struct objtool_file *file)
> > > > +{
> > > > +   return 127;
> > > > +}
> > > > +
> > > > +int __attribute__ ((weak)) create_orc_sections(struct objtool_file 
> > > > *file)
> > > > +{
> > > > +   return 127;
> > > > +}
> > > 
> > > I think the aliased "missing_" functions are no longer needed, right?
> > > i.e. can we just have weak versions of check() and orc_dump()?
> > 
> > Oops, Yeah, we can remove those aliases. I can fix and resend this one if 
> > you
> > like. 
> 
> I made that change along with Julien's suggestion, and also made a few
> other changes to the weak file: a __weak macro and some error messages.
> 
> Does this look ok?

Yes, looks great to me. Thanks!

> 
> From: Matt Helsley 
> Subject: [PATCH] objtool: Enable compilation of objtool for all architectures
> 
> Objtool currently only compiles for x86 architectures. This is
> fine as it presently does not support tooling for other
> architectures. However, we would like to be able to convert other
> kernel tools to run as objtool sub commands because they too
> process ELF object files. This will allow us to convert tools
> such as recordmcount to use objtool's ELF code.
> 
> Since much of recordmcount's ELF code is copy-paste code to/from
> a variety of other kernel tools (look at modpost for example) this
> means that if we can convert recordmcount we can convert more.
> 
> We define weak definitions for subcommand entry functions and other weak
> definitions for shared functions critical to building existing
> subcommands. These return 127 when the command is missing which signify
> tools that do not exist on all architectures.  In this case the "check"
> and "orc" tools do not exist on all architectures so we only add them
> for x86. Future changes adding support for "check", to arm64 for
> example, can then modify the SUBCMD_CHECK variable when building for
> arm64.
> 
> Objtool is not currently wired in to KConfig to be built for other
> architectures because it's not needed for those architectures and
> there are no commands it supports other than those for x86. As more
> command support is enabled on various architectures the necessary
> KConfig changes can be made (e.g. adding "STACK_VALIDATION") to
> trigger building objtool.
> 
> [ jpoimboe: remove aliases, add __weak macro, add error messages ]
> 
> Cc: Julien Thierry 
> Signed-off-by: Matt Helsley 
> Signed-off-by: Josh Poimboeuf 
> ---
>  tools/objtool/Build   | 13 
>  tools/objtool/Makefile| 10 +
>  tools/objtool/arch.h  |  4 +++-
>  tools/objtool/builtin-check.c |  2 +-
>  tools/objtool/builtin-orc.c   |  3 +--
>  tools/objtool/check.c |  4 ++--
>  tools/objtool/check.h |  4 
>  tools/objtool/objtool.h   |  5 +
>  tools/objtool/orc.h   | 18 
>  tools/objtool/orc_dump.c  |  3 ++-
>  tools/objtool/orc_gen.c   |  1 -
>  tools/objtool/weak.c  | 40 +++
>  12 files changed, 73 insertions(+), 34 deletions(-)
>  delete mode 100644 tools/objtool/orc.h
>  create mode 100644 tools/objtool/weak.c
> 
> diff --git a/tools/objtool/Build b/tools/objtool/Build
> index 66f44f5cd2a6..b7222d5cc7bc 100644
> --- a/tools/objtool/Build
> +++ b/tools/objtool/Build
> @@ -1,11 +1,16 @@
>  objtool-y += arch/$(SRCARCH)/
> +
> +objtool-y += weak.o
> +
> +objtool-$(SUBCMD_CHECK) += check.o
> +objtool-$(SUBCMD_CHECK) += special.o
> +objtool-$(SUBCMD_ORC) += check.o
> +objtool-$(SUBCMD_ORC) += orc_gen.o
> +objtool-$(SUBCMD_ORC) += orc_dump.o
> +
>  objtool-y += builtin-check.o
>  objtool-y += builtin-orc.o
> -objtool-y += check.o
> -objtool-y += orc_gen.o
> -objtool-y += orc_dump.o
>  objtool-y += elf.o
> -objtool-y += special.o
>  objtool-y += objtool.o
>  
>  objtool-y += libstring.o
> diff --git

[PATCH] staging: rtl8192e: Using comparison to true is error prone

2020-05-20 Thread John Oldman

fix below issue reported by checkpatch.pl:

CHECK: Using comparison to true is error prone
CHECK: Using comparison to false is error prone

Signed-off-by: John Oldman 
---
 drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c 
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index b093b5629171..5b1392deb0a7 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -514,7 +514,7 @@ static void rtw_dev_remove(struct sdio_func *func)
 
rtw_unregister_netdevs(dvobj);
 
-   if (padapter->bSurpriseRemoved == false) {
+   if (!padapter->bSurpriseRemoved) {
int err;
 
/* test surprise remove */
@@ -554,12 +554,12 @@ static int rtw_sdio_suspend(struct device *dev)
struct adapter *padapter = psdpriv->if1;
struct debug_priv *pdbgpriv = >drv_dbg;
 
-   if (padapter->bDriverStopped == true) {
+   if (padapter->bDriverStopped) {
DBG_871X("%s bDriverStopped = %d\n", __func__, 
padapter->bDriverStopped);
return 0;
}
 
-   if (pwrpriv->bInSuspend == true) {
+   if (pwrpriv->bInSuspend) {
DBG_871X("%s bInSuspend = %d\n", __func__, pwrpriv->bInSuspend);
pdbgpriv->dbg_suspend_error_cnt++;
return 0;
@@ -574,7 +574,7 @@ static int rtw_resume_process(struct adapter *padapter)
struct dvobj_priv *psdpriv = padapter->dvobj;
struct debug_priv *pdbgpriv = >drv_dbg;
 
-   if (pwrpriv->bInSuspend == false) {
+   if (!pwrpriv->bInSuspend) {
pdbgpriv->dbg_resume_error_cnt++;
DBG_871X("%s bInSuspend = %d\n", __func__, pwrpriv->bInSuspend);
return -1;
-- 
2.17.1

Re: [PATCH] PCI: tegra: fix runtime pm imbalance on error

2020-05-20 Thread Bjorn Helgaas

On Wed, May 20, 2020 at 11:59:08AM +0200, Thierry Reding wrote:
> On Wed, May 20, 2020 at 04:52:23PM +0800, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > it returns an error code. Thus a pairing decrement is needed on
> 
> s/even it/even when it/
> 
> Might also be a good idea to use a different subject prefix because I
> was almost not going to look at the other patch, taking this to be a
> replacement for it.

Amen.  This would be a good change to start using "PCI: tegra194" or
something for pcie-tegra194.c.  Or will there be tegra195, tegra 196,
etc added to this driver?

Also, please capitalize the first word and "PM" in the subjects:

  PCI: tegra194: Fix runtime PM imbalance on error

Bjorn

Re: [PATCH] mm, page_alloc: skip ->waternark_boost for atomic order-0 allocations

2020-05-20 Thread Charan Teja Kalla

Thank you Andrew for the comments..

On 5/20/2020 7:10 AM, Andrew Morton wrote:
> On Tue, 19 May 2020 15:28:04 +0530 Charan Teja Reddy 
>  wrote:
> 
>> When boosting is enabled, it is observed that rate of atomic order-0
>> allocation failures are high due to the fact that free levels in the
>> system are checked with ->watermark_boost offset. This is not a problem
>> for sleepable allocations but for atomic allocations which looks like
>> regression.
>>
>> This problem is seen frequently on system setup of Android kernel
>> running on Snapdragon hardware with 4GB RAM size. When no extfrag event
>> occurred in the system, ->watermark_boost factor is zero, thus the
>> watermark configurations in the system are:
>>_watermark = (
>>   [WMARK_MIN] = 1272, --> ~5MB
>>   [WMARK_LOW] = 9067, --> ~36MB
>>   [WMARK_HIGH] = 9385), --> ~38MB
>>watermark_boost = 0
>>
>> After launching some memory hungry applications in Android which can
>> cause extfrag events in the system to an extent that ->watermark_boost
>> can be set to max i.e. default boost factor makes it to 150% of high
>> watermark.
>>_watermark = (
>>   [WMARK_MIN] = 1272, --> ~5MB
>>   [WMARK_LOW] = 9067, --> ~36MB
>>   [WMARK_HIGH] = 9385), --> ~38MB
>>watermark_boost = 14077, -->~57MB
>>
>> With default system configuration, for an atomic order-0 allocation to
>> succeed, having free memory of ~2MB will suffice. But boosting makes
>> the min_wmark to ~61MB thus for an atomic order-0 allocation to be
>> successful system should have minimum of ~23MB of free memory(from
>> calculations of zone_watermark_ok(), min = 3/4(min/2)). But failures are
>> observed despite system is having ~20MB of free memory. In the testing,
>> this is reproducible as early as first 300secs since boot and with
>> furtherlowram configurations(<2GB) it is observed as early as first
>> 150secs since boot.
>>
>> These failures can be avoided by excluding the ->watermark_boost in
>> watermark caluculations for atomic order-0 allocations.
> 
> Seems sensible.
> 
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -3709,6 +3709,18 @@ static bool zone_allows_reclaim(struct zone 
>> *local_zone, struct zone *zone)
>>  }
>>  
>>  mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK);
>> +/*
>> + * Allow GFP_ATOMIC order-0 allocations to exclude the
>> + * zone->watermark_boost in its watermark calculations.
>> + * We rely on the ALLOC_ flags set for GFP_ATOMIC
>> + * requests in gfp_to_alloc_flags() for this. Reason not to
>> + * use the GFP_ATOMIC directly is that we want to fall back
>> + * to slow path thus wake up kswapd.
> 
> Nice comment, but I don't understand it ;)
> 
> Why would testing gfp_mask prevent us from waking kswapd?

This piece of code is in the common function get_page_from_freelist()
which will be called in the below order:
1) alloc_pages() with alloc_flags = ALLOC_WMARK_LOW. If watermark check
fails here then,
2) Allocation request will fall back to the slow path,
__alloc_pages_slowpath with alloc_flags = ALLOC_WMARK_MIN, **where it
wakes up kswapd**.

If I use the GFP_ATOMIC directly then even if watermarks are boosted
(and kswapd is yet to wake up), then atomic allocation can return
success from 1) with out even waking up kswapd. This doesn't seem correct.

> 
>> + */
>> +if (unlikely(!order && !(alloc_flags & ALLOC_WMARK_MASK) &&
>> + (alloc_flags & (ALLOC_HARDER | ALLOC_HIGH {
>> +mark = zone->_watermark[WMARK_MIN];
>> +}
> 
> Why is this not implemented for higher-order allocation attempts?

I don't think that higher-order allocation failures are such critical, I
meant that there will be no critical users who can rely on higher-order
atomic allocations to be successful. Please correct me If I am wrong
here. Atleast this is the case on Android systems..

> 
>>  if (!zone_watermark_fast(zone, order, mark,
>> ac->highest_zoneidx, alloc_flags)) {
>>  int ret;
> 

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

Re: [PATCH] KVM: x86: allow KVM_STATE_NESTED_MTF_PENDING in kvm_state flags

Paolo Bonzini  writes:

> The migration functionality was left incomplete in commit 5ef8acbdd687
> ("KVM: nVMX: Emulate MTF when performing instruction emulation", 2020-02-23),
> fix it.
>
> Fixes: 5ef8acbdd687 ("KVM: nVMX: Emulate MTF when performing instruction 
> emulation")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/x86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 4f55a44951c3..0001b2addc66 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4626,7 +4626,7 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>  
>   if (kvm_state.flags &
>   ~(KVM_STATE_NESTED_RUN_PENDING | KVM_STATE_NESTED_GUEST_MODE
> -   | KVM_STATE_NESTED_EVMCS))
> +   | KVM_STATE_NESTED_EVMCS | KVM_STATE_NESTED_MTF_PENDING))
>   break;
>  
>   /* nested_run_pending implies guest_mode.  */

Reviewed-by: Vitaly Kuznetsov 

-- 
Vitaly

Re: [PATCH v1 2/6] arm/smmu: Add auxiliary domain support for arm-smmuv2

2020-05-20 Thread Rob Clark

On Wed, May 20, 2020 at 8:13 AM Jordan Crouse  wrote:
>
> On Wed, May 20, 2020 at 01:57:01PM +0100, Will Deacon wrote:
> > On Mon, May 18, 2020 at 08:50:27AM -0700, Rob Clark wrote:
> > > On Mon, May 18, 2020 at 8:18 AM Will Deacon  wrote:
> > > > On Wed, Mar 18, 2020 at 04:43:07PM -0700, Rob Clark wrote:
> > > > > We do in fact need live domain switching, that is really the whole
> > > > > point.  The GPU CP (command processor/parser) is directly updating
> > > > > TTBR0 and triggering TLB flush, asynchronously from the CPU.
> > > > >
> > > > > And I think the answer about ASID is easy (on current hw).. it must 
> > > > > be zero[*].
> > > >
> > > > Using ASID zero is really bad, because it means that you will end up 
> > > > sharing
> > > > TLB entries with whichever device is using context bank 0.
> > > >
> > > > Is the SMMU only used by the GPU in your SoC?
> > > >
> > >
> > > yes, the snapdragon SoCs have two SMMU instances, one used by the GPU,
> > > where ASID0/cb0 is the gpu itself, and another cb is the GMU
> > > (basically power control for the gpu), and the second SMMU is
> > > everything else.
> >
> > Right, in which case I'm starting to think that we should treat this GPU
> > SMMU instance specially. Give it its own compatible string (looks like you
> > need this for HUPCFG anyway) and hook in via arm_smmu_impl_init(). You can
> > then set IO_PGTABLE_QUIRK_ARM_TTBR1 when talking to the io-pgtable code
> > without having to add a domain attribute.
>
> If we did this via a special GPU SMMU instance then we could also create and
> register a dummy TTBR0 instance along with the TTBR1 instance and then we
> wouldn't need to worry about the aux domains at all.
>
> > With that. you'll need to find a way to allow the GPU driver to call into
> > your own hooks for getting at the TTBR0 tables -- given that you're
> > programming these in the hardware, I don't think it makes sense to expose
> > that in the IOMMU API, since most devices won't be able to do anything with
> > that data. Perhaps you could install a couple of function pointers
> > (subdomain_alloc/subdomain_free) in the GPU device when you see it appear
> > from the SMMU driver? Alternatively, you could make an io_pgtable_cfg
> > available so that the GPU driver can interface with io-pgtable directly.
>
> I don't want to speak for Rob but I think that this is the same direction 
> we've
> landed on. If we use the implementation specific code to initialize the base
> pagetables then the GPU driver can use io-pgtable directly. We can easily
> construct an io_pgtable_cfg. This feature will only be available for opt-in
> GPU targets that will have a known configuration.

Agreed about using io-pgtable helpers directly.. the gpu's use-case is
pretty far different from anything normal/sane, and I don't think it
is worth designing some generic iommu interfaces with precisely one
user[*].  We just need enough in arm-smmu(/-impl) to bootstrap things
when we power up the gpu.

BR,
-R

[*] all the other gpu's that I've seen so far, even if they sit behind
an iommu, they have their own internal mmu

> The only gotcha is TLB maintenance but Rob and I have ideas about coordinating
> with the GPU hardware (which has to do a TLBIALL during a switch anyway) and 
> we
> can always use the iommu_tlb_flush_all() hammer from software if we really 
> need
> it. It might take a bit of thought, but it is doable.
>
> > Yes, it's ugly, but I don't think it's worth trying to abstract this.
>
> I'm not sure how ugly it is. I've always operated under the assumption that 
> the
> GPU SMMU was special (though it had generic registers) just because of where 
> it
> was and how it it was used.  In the long run baking in a implementation 
> specific
> solution would probably be preferable to lots of domain attributes and aux
> domains that would never be used except by us.
>
> > Thoughts? It's taken me a long time to figure out what's going on here,
> > so sorry if it feels like I'm leading you round the houses.
>
> I'll hack on this and try to get something in place. It might be dumber on the
> GPU side than we would like but it would at least spur some more conversation.
>
> Jordan
>
> > Will
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

[PATCH v2] x86/mm: Change so poison pages are either unmapped or marked uncacheable

2020-05-20 Thread Luck, Tony

An interesting thing happened when a guest Linux instance took
a machine check. The VMM unmapped the bad page from guest physical
space and passed the machine check to the guest.

Linux took all the normal actions to offline the page from the process
that was using it. But then guest Linux crashed because it said there
was a second machine check inside the kernel with this stack trace:

do_memory_failure
set_mce_nospec
 set_memory_uc
  _set_memory_uc
   change_page_attr_set_clr
cpa_flush
 clflush_cache_range_opt

This was odd, because a CLFLUSH instruction shouldn't raise a machine
check (it isn't consuming the data). Further investigation showed that
the VMM had passed in another machine check because is appeared that the
guest was accessing the bad page.

Fix is to check the scope of the poison by checking the MCi_MISC register.
If the entire page is affected, then unmap the page. If only part of the
page is affected, then mark the page as uncacheable.

This assumes that VMMs will do the logical thing and pass in the "whole
page scope" via the MCi_MISC register (since they unmapped the entire
page).

Reported-by: Jue Wang 
Tested-by: Jue Wang 
Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()")
Cc: 
Signed-off-by: Tony Luck 
---
Boris wrote:
> Maybe I'm not making myself clear enough here: I'm talking about using
> a *special* MCE signature which says "your mapping has disappeared from
> underneath you." Maybe a bit in MCi_MISC which the hw doesn't use. Or
> some other deprecated bit, whatever.

My reactions (in order)
1) How can I do that for 10 year old h/w?
2) Oh wait, Boris is talking about the VMM faking a signature to the guest.
   They can mess with whatever bits they want.
3) Unused/deprecated bits are in short supply. Taking one over and getting
   all the VMM vendors to agree to this "standard" is going to be a huge effort.
4) Could we do something inside the existing architecture?
5) MCi_MISC uses low order bits to indicate the "blast radius" of an error
6) Asks Jue "Could you set those MCi_MISC bits to say the whole page is gone?
7) Jue: We already do that!
8) Me: writes this patch

 arch/x86/include/asm/set_memory.h | 19 +--
 arch/x86/kernel/cpu/mce/core.c| 11 +--
 include/linux/set_memory.h|  2 +-
 3 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/set_memory.h 
b/arch/x86/include/asm/set_memory.h
index ec2c0a094b5d..5948218f35c5 100644
--- a/arch/x86/include/asm/set_memory.h
+++ b/arch/x86/include/asm/set_memory.h
@@ -86,28 +86,35 @@ int set_direct_map_default_noflush(struct page *page);
 extern int kernel_set_to_readonly;

 #ifdef CONFIG_X86_64
-static inline int set_mce_nospec(unsigned long pfn)
+/*
+ * Prevent speculative access to the page by either unmapping
+ * it (if we do not require access to any part of the page) or
+ * marking it uncacheable (if we want to try to retrieve data
+ * from non-poisoned lines in the page).
+ */
+static inline int set_mce_nospec(unsigned long pfn, bool unmap)
 {
unsigned long decoy_addr;
int rc;

/*
-* Mark the linear address as UC to make sure we don't log more
-* errors because of speculative access to the page.
 * We would like to just call:
-*  set_memory_uc((unsigned long)pfn_to_kaddr(pfn), 1);
+*  set_memory_XX((unsigned long)pfn_to_kaddr(pfn), 1);
 * but doing that would radically increase the odds of a
 * speculative access to the poison page because we'd have
 * the virtual address of the kernel 1:1 mapping sitting
 * around in registers.
 * Instead we get tricky.  We create a non-canonical address
 * that looks just like the one we want, but has bit 63 flipped.
-* This relies on set_memory_uc() properly sanitizing any __pa()
+* This relies on set_memory_XX() properly sanitizing any __pa()
 * results with __PHYSICAL_MASK or PTE_PFN_MASK.
 */
decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63));

-   rc = set_memory_uc(decoy_addr, 1);
+   if (unmap)
+   rc = set_memory_np(decoy_addr, 1);
+   else
+   rc = set_memory_uc(decoy_addr, 1);
if (rc)
pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn);
return rc;
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 54165f3569e8..c1a480a27164 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -529,6 +529,13 @@ bool mce_is_memory_error(struct mce *m)
 }
 EXPORT_SYMBOL_GPL(mce_is_memory_error);

+static bool whole_page(struct mce *m)
+{
+   if (!mca_cfg.ser || !(m->status & MCI_STATUS_MISCV))
+   return true;
+   return MCI_MISC_ADDR_LSB(m->misc) >= PAGE_SHIFT;
+}
+
 bool

[PATCH v5 4/4] iio: magnetometer: ak8975: Add gpio reset support

According to AK09911 datasheet, if reset gpio is provided then
deassert reset on ak8975_power_on() and assert reset on ak8975_power_off().

Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.

AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheet says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.

Signed-off-by: Jonathan Albrieux 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Stephan Gerhold 
---
 drivers/iio/magnetometer/ak8975.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/iio/magnetometer/ak8975.c 
b/drivers/iio/magnetometer/ak8975.c
index fd368455cd7b..a23422aad97d 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -358,6 +358,7 @@ struct ak8975_data {
u8  asa[3];
longraw_to_gauss[3];
struct gpio_desc*eoc_gpiod;
+   struct gpio_desc*reset_gpiod;
int eoc_irq;
wait_queue_head_t   data_ready_queue;
unsigned long   flags;
@@ -384,6 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
 "Failed to enable specified Vid supply\n");
return ret;
}
+
+   gpiod_set_value_cansleep(data->reset_gpiod, 0);
+
/*
 * According to the datasheet the power supply rise time is 200us
 * and the minimum wait time before mode setting is 100us, in
@@ -396,6 +400,8 @@ static int ak8975_power_on(const struct ak8975_data *data)
 /* Disable attached power regulator if any. */
 static void ak8975_power_off(const struct ak8975_data *data)
 {
+   gpiod_set_value_cansleep(data->reset_gpiod, 1);
+
regulator_disable(data->vid);
regulator_disable(data->vdd);
 }
@@ -839,6 +845,7 @@ static int ak8975_probe(struct i2c_client *client,
struct ak8975_data *data;
struct iio_dev *indio_dev;
struct gpio_desc *eoc_gpiod;
+   struct gpio_desc *reset_gpiod;
const void *match;
unsigned int i;
int err;
@@ -856,6 +863,16 @@ static int ak8975_probe(struct i2c_client *client,
if (eoc_gpiod)
gpiod_set_consumer_name(eoc_gpiod, "ak_8975");
 
+   /*
+* According to AK09911 datasheet, if reset GPIO is provided then
+* deassert reset on ak8975_power_on() and assert reset on
+* ak8975_power_off().
+*/
+   reset_gpiod = devm_gpiod_get_optional(>dev,
+ "reset", GPIOD_OUT_HIGH);
+   if (IS_ERR(reset_gpiod))
+   return PTR_ERR(reset_gpiod);
+
/* Register with IIO */
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
if (indio_dev == NULL)
@@ -866,6 +883,7 @@ static int ak8975_probe(struct i2c_client *client,
 
data->client = client;
data->eoc_gpiod = eoc_gpiod;
+   data->reset_gpiod = reset_gpiod;
data->eoc_irq = 0;
 
err = iio_read_mount_matrix(>dev, "mount-matrix", 
>orientation);
-- 
2.17.1

[PATCH v5 3/4] iio: magnetometer: ak8975: Fix typo, uniform measurement unit style

Minor comment style edits.

Signed-off-by: Jonathan Albrieux 
Reviewed-by: Andy Shevchenko 
---
 drivers/iio/magnetometer/ak8975.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/magnetometer/ak8975.c 
b/drivers/iio/magnetometer/ak8975.c
index 3c881541ae72..fd368455cd7b 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -385,9 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
return ret;
}
/*
-* According to the datasheet the power supply rise time i 200us
+* According to the datasheet the power supply rise time is 200us
 * and the minimum wait time before mode setting is 100us, in
-* total 300 us. Add some margin and say minimum 500us here.
+* total 300us. Add some margin and say minimum 500us here.
 */
usleep_range(500, 1000);
return 0;
-- 
2.17.1

[PATCH v5 1/4] dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add maintainer

Converts documentation from txt format to yaml.

Signed-off-by: Jonathan Albrieux 
---
 .../bindings/iio/magnetometer/ak8975.txt  | 30 
 .../bindings/iio/magnetometer/ak8975.yaml | 71 +++
 2 files changed, 71 insertions(+), 30 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
 create mode 100644 
Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml

diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt 
b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
deleted file mode 100644
index aa67ceb0d4e0..
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* AsahiKASEI AK8975 magnetometer sensor
-
-Required properties:
-
-  - compatible : should be "asahi-kasei,ak8975"
-  - reg : the I2C address of the magnetometer
-
-Optional properties:
-
-  - gpios : should be device tree identifier of the magnetometer DRDY pin
-  - vdd-supply: an optional regulator that needs to be on to provide VDD
-  - mount-matrix: an optional 3x3 mounting rotation matrix
-
-Example:
-
-ak8975@c {
-compatible = "asahi-kasei,ak8975";
-reg = <0x0c>;
-gpios = < 7 0>;
-vdd-supply = <_3v3_gnss>;
-mount-matrix = "-0.984807753012208",  /* x0 */
-   "0",   /* y0 */
-   "-0.173648177666930",  /* z0 */
-   "0",   /* x1 */
-   "-1",  /* y1 */
-   "0",   /* z1 */
-   "-0.173648177666930",  /* x2 */
-   "0",   /* y2 */
-   "0.984807753012208";   /* z2 */
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml 
b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
new file mode 100644
index ..8bde423a2ffa
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/ak8975.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AsahiKASEI AK8975 magnetometer sensor
+
+maintainers:
+  - Jonathan Albrieux 
+
+properties:
+  compatible:
+oneOf:
+  - const: asahi-kasei,ak8975
+  - const: asahi-kasei,ak8963
+  - const: asahi-kasei,ak09911
+  - const: asahi-kasei,ak09912
+  - const: ak8975
+deprecated: true
+  - const: ak8963
+deprecated: true
+  - const: ak09911
+deprecated: true
+  - const: ak09912
+deprecated: true
+
+  reg:
+maxItems: 1
+description: the I2C address of the magnetometer
+
+  gpios:
+description: should be device tree identifier of the magnetometer DRDY pin
+
+  vdd-supply:
+maxItems: 1
+description: |
+  an optional regulator that needs to be on to provide VDD power to
+  the sensor.
+
+  mount-matrix:
+description: an optional 3x3 mounting rotation matrix
+
+required:
+  - compatible
+  - reg
+
+examples:
+  - |
+#include 
+i2c@78b7000 {
+reg = <0x78b6000 0x600>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+magnetometer@c {
+compatible = "asahi-kasei,ak8975";
+reg = <0x0c>;
+gpios = < 7 GPIO_ACTIVE_HIGH>;
+vdd-supply = <_3v3_gnss>;
+mount-matrix = "-0.984807753012208",  /* x0 */
+   "0",   /* y0 */
+   "-0.173648177666930",  /* z0 */
+   "0",   /* x1 */
+   "-1",  /* y1 */
+   "0",   /* z1 */
+   "-0.173648177666930",  /* x2 */
+   "0",   /* y2 */
+   "0.984807753012208";   /* z2 */
+};
+};
-- 
2.17.1

[PATCH v5 0/4] iio: magnetometer: ak8975: Add gpio reset support

v5:
 - add maintainer

v4:
 - fix some typo
 - use gpio's dt-bindings for more clarity in documentation
 - set compatible properties without vendor prefix as deprecated
https://lore.kernel.org/linux-iio/20200520073125.30808-1-jonathan.albri...@gmail.com/

v3:
 - fix patch messages style
 - align reset gpio comment to kernel doc reccomendation
 - introduce changelog
https://lore.kernel.org/linux-iio/20200519124402.26076-1-jonathan.albri...@gmail.com/

v2:
 - rewording of reset gpio comment and patch messages to better clarify
   reset gpio behaviour
https://lore.kernel.org/linux-iio/20200518133645.19127-1-jonathan.albri...@gmail.com/

v1:
 - initial patch submission
https://lore.kernel.org/linux-iio/20200519065749.4624-1-jonathan.albri...@gmail.com/

Convert documentation from txt format to yaml. Add documentation about
reset-gpio.

Deassert reset on ak8975_power_on(), assert reset on ak8975_power_off().

Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.

AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheet says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.

Jonathan Albrieux (4):
  dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add
maintainer
  dt-bindings: iio: magnetometer: ak8975: add gpio reset support
  iio: magnetometer: ak8975: Fix typo, uniform measurement unit style
  iio: magnetometer: ak8975: Add gpio reset support

 .../bindings/iio/magnetometer/ak8975.txt  | 30 
 .../bindings/iio/magnetometer/ak8975.yaml | 77 +++
 drivers/iio/magnetometer/ak8975.c | 22 +-
 3 files changed, 97 insertions(+), 32 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
 create mode 100644 
Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml

-- 
2.17.1

[PATCH v5 2/4] dt-bindings: iio: magnetometer: ak8975: add gpio reset support

Add reset-gpio support.

Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.

AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheet says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.

Signed-off-by: Jonathan Albrieux 
---
 .../devicetree/bindings/iio/magnetometer/ak8975.yaml| 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml 
b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
index 8bde423a2ffa..aba9ced7b6da 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
@@ -41,6 +41,11 @@ properties:
   mount-matrix:
 description: an optional 3x3 mounting rotation matrix
 
+  reset-gpio:
+description: |
+  an optional pin needed for AK09911 to set the reset state. This should
+  be usually active low
+
 required:
   - compatible
   - reg
@@ -58,6 +63,7 @@ examples:
 reg = <0x0c>;
 gpios = < 7 GPIO_ACTIVE_HIGH>;
 vdd-supply = <_3v3_gnss>;
+reset-gpio = < 111 GPIO_ACTIVE_LOW>;
 mount-matrix = "-0.984807753012208",  /* x0 */
"0",   /* y0 */
"-0.173648177666930",  /* z0 */
-- 
2.17.1

Re: [PATCH 2/2] kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally

Maxim Levitsky  writes:

> This msr is only available when the host supports WAITPKG feature.
>
> This breaks a nested guest, if the L1 hypervisor is set to ignore
> unknown msrs, because the only other safety check that the
> kernel does is that it attempts to read the msr and
> rejects it if it gets an exception.
>
> Fixes: 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL
>
> Signed-off-by: Maxim Levitsky 
> ---
>  arch/x86/kvm/x86.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index fe3a24fd6b263..9c507b32b1b77 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
>   if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
>   min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))
>   continue;
> + break;
> + case MSR_IA32_UMWAIT_CONTROL:
> + if (!kvm_cpu_cap_has(X86_FEATURE_WAITPKG))
> + continue;

I'm probably missing something but (if I understand correctly) the only
effect of dropping MSR_IA32_UMWAIT_CONTROL from msrs_to_save would be
that KVM userspace won't see it in e.g. KVM_GET_MSR_INDEX_LIST. But why
is this causing an issue? I see both vmx_get_msr()/vmx_set_msr() have
'host_initiated' check:

   case MSR_IA32_UMWAIT_CONTROL:
if (!msr_info->host_initiated && !vmx_has_waitpkg(vmx))
return 1;

so KVM userspace should be able to read/write this MSR even when there's
no hardware support for it. Or who's trying to read/write it?

Also, kvm_cpu_cap_has() check is not equal to vmx_has_waitpkg() which
checks secondary execution controls.

>   default:
>   break;
>   }

-- 
Vitaly

[PATCH v6 18/19] mtd: spi-nor: spansion: add support for Cypress Semper flash

The Cypress Semper flash is an xSPI compliant octal DTR flash. Add
support for using it in octal DTR mode.

The flash by default boots in a hybrid sector mode. But the sector map
table on the part I had was programmed incorrectly and the SMPT values
on the flash don't match the public datasheet. Specifically, in some
places erase type 3 was used instead of 4. In addition, the region sizes
were incorrect in some places. So, for testing I set CFR3N[3] to enable
uniform sector sizes. Since the uniform sector mode bit is a
non-volatile bit, this series does not change it to avoid making any
permanent changes to the flash configuration. The correct data to
implement a fixup is not available right now and will be done in a
follow-up patch if needed.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/spansion.c | 167 +
 1 file changed, 167 insertions(+)

diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index 88183eba8ac1..e5dc36b70e4e 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -8,6 +8,169 @@
 
 #include "core.h"
 
+/* For Cypress flash. */
+#define SPINOR_OP_RD_ANY_REG   0x65/* Read any register */
+#define SPINOR_OP_WR_ANY_REG   0x71/* Write any register */
+#define SPINOR_REG_CYPRESS_CFR2V   0x0083
+#define SPINOR_REG_CYPRESS_CFR2V_MEMLAT_11_24  0xb
+#define SPINOR_REG_CYPRESS_CFR3V   0x0084
+#define SPINOR_REG_CYPRESS_CFR3V_PGSZ  BIT(4) /* Page size. */
+#define SPINOR_REG_CYPRESS_CFR5V   0x0086
+#define SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN0x3
+#define SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_DS0
+#define SPINOR_OP_CYPRESS_RD_FAST  0xee
+
+/**
+ * spi_nor_cypress_octal_dtr_enable() - Enable octal DTR on Cypress flashes.
+ * @nor:   pointer to a 'struct spi_nor'
+ *
+ * This also sets the memory access latency cycles to 24 to allow the flash to
+ * run at up to 200MHz.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_cypress_octal_dtr_enable(struct spi_nor *nor, bool enable)
+{
+   struct spi_mem_op op;
+   u8 *buf = nor->bouncebuf;
+   u8 addr_width;
+   int ret;
+
+   if (enable)
+   addr_width = 3;
+   else
+   addr_width = 4;
+
+   if (enable) {
+   /* Use 24 dummy cycles for memory array reads. */
+   ret = spi_nor_write_enable(nor);
+   if (ret)
+   return ret;
+
+   *buf = SPINOR_REG_CYPRESS_CFR2V_MEMLAT_11_24;
+   op = (struct spi_mem_op)
+   SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
+  SPI_MEM_OP_ADDR(addr_width,
+  SPINOR_REG_CYPRESS_CFR2V,
+  1),
+  SPI_MEM_OP_NO_DUMMY,
+  SPI_MEM_OP_DATA_OUT(1, buf, 1));
+   ret = spi_mem_exec_op(nor->spimem, );
+   if (ret) {
+   dev_warn(nor->dev,
+"failed to set default memory latency value: 
%d\n",
+ret);
+   return ret;
+   }
+   ret = spi_nor_wait_till_ready(nor);
+   if (ret)
+   return ret;
+
+   nor->read_dummy = 24;
+   }
+
+   /* Set/unset the octal and DTR enable bits. */
+   ret = spi_nor_write_enable(nor);
+   if (ret)
+   return ret;
+
+   if (enable)
+   *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN;
+   else
+   *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_DS;
+   op = (struct spi_mem_op)
+   SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
+  SPI_MEM_OP_ADDR(addr_width,
+  SPINOR_REG_CYPRESS_CFR5V,
+  1),
+  SPI_MEM_OP_NO_DUMMY,
+  SPI_MEM_OP_DATA_OUT(1, buf, 1));
+
+   if (!enable)
+   spi_nor_spimem_setup_op(nor, , SNOR_PROTO_8_8_8_DTR);
+
+   ret = spi_mem_exec_op(nor->spimem, );
+   if (ret) {
+   dev_warn(nor->dev, "Failed to enable octal DTR mode\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static void s28hs512t_default_init(struct spi_nor *nor)
+{
+   nor->params->octal_dtr_enable = spi_nor_cypress_octal_dtr_enable;
+}
+
+static void s28hs512t_post_sfdp_fixup(struct spi_nor *nor)
+{
+   /*
+* On older versions of the flash the xSPI Profile 1.0 table has the
+* 8D-8D-8D Fast Read opcode as 0x00. But it actually should be 0xEE.
+*/
+   if (nor->params->reads[SNOR_CMD_READ_8_8_8_DTR].opcode == 0)
+

[PATCH] Bluetooth: hci_qca: Fix uninitialized access to hdev

2020-05-20 Thread Abhishek Pandit-Subedi

hdev is always allocated and not only when power control is required.

Reported-by: Dan Carpenter 
Signed-off-by: Abhishek Pandit-Subedi 
---

 drivers/bluetooth/hci_qca.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 26efe822f6e58..e4a68238fcb93 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1947,8 +1947,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
}
}
 
+   hdev = qcadev->serdev_hu.hdev;
+
if (power_ctrl_enabled) {
-   hdev = qcadev->serdev_hu.hdev;
set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks);
hdev->shutdown = qca_power_off;
}
-- 
2.27.0.rc0.183.gde8f92d652-goog

[PATCH v6 19/19] mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode

Since this flash doesn't have a Profile 1.0 table, the Octal DTR
capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
fast read settings.

Enable Octal DTR mode with 20 dummy cycles to allow running at the
maximum supported frequency of 200Mhz.

The flash supports the soft reset sequence. So, add the flag in the
flash's info.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/micron-st.c | 112 +++-
 1 file changed, 111 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index 3dca5b9af3b6..3414c44a5c96 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -8,10 +8,120 @@
 
 #include "core.h"
 
+#define SPINOR_OP_MT_DTR_RD0xfd/* Fast Read opcode in DTR mode */
+#define SPINOR_OP_MT_RD_ANY_REG0x85/* Read volatile register */
+#define SPINOR_OP_MT_WR_ANY_REG0x81/* Write volatile register */
+#define SPINOR_REG_MT_CFR0V0x00/* For setting octal DTR mode */
+#define SPINOR_REG_MT_CFR1V0x01/* For setting dummy cycles */
+#define SPINOR_MT_DTR_NO_DQS   0xc7/* Enable Octal DTR without DQS. */
+#define SPINOR_MT_EXSPI0xff/* Enable Extended SPI 
(default) */
+
+static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor, bool enable)
+{
+   struct spi_mem_op op;
+   u8 *buf = nor->bouncebuf;
+   u8 addr_width;
+   int ret;
+
+   if (enable)
+   addr_width = 3;
+   else
+   addr_width = 4;
+
+   ret = spi_nor_write_enable(nor);
+   if (ret)
+   return ret;
+
+   if (enable)
+   *buf = SPINOR_MT_DTR_NO_DQS;
+   else
+   *buf = SPINOR_MT_EXSPI;
+   op = (struct spi_mem_op)
+   SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
+  SPI_MEM_OP_ADDR(addr_width, SPINOR_REG_MT_CFR0V, 1),
+  SPI_MEM_OP_NO_DUMMY,
+  SPI_MEM_OP_DATA_OUT(1, buf, 1));
+
+   if (!enable)
+   spi_nor_spimem_setup_op(nor, , SNOR_PROTO_8_8_8_DTR);
+
+   ret = spi_mem_exec_op(nor->spimem, );
+   if (ret) {
+   dev_err(nor->dev, "Failed to enable octal DTR mode\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static int mt35xu512aba_setup(struct spi_nor *nor,
+ const struct spi_nor_hwcaps *hwcaps)
+{
+   struct spi_mem_op op;
+   u8 *buf = nor->bouncebuf;
+   u8 addr_width = 3;
+   int ret;
+
+   if (!nor->spimem) {
+   dev_err(nor->dev,
+   "operation not supported for non-spimem drivers\n");
+   return -ENOTSUPP;
+   }
+
+   /* Set dummy cycles for Fast Read to the default of 20. */
+   ret = spi_nor_write_enable(nor);
+   if (ret)
+   return ret;
+
+   *buf = 20;
+   op = (struct spi_mem_op)
+   SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
+  SPI_MEM_OP_ADDR(addr_width, SPINOR_REG_MT_CFR1V, 1),
+  SPI_MEM_OP_NO_DUMMY,
+  SPI_MEM_OP_DATA_OUT(1, buf, 1));
+   ret = spi_mem_exec_op(nor->spimem, );
+   if (ret)
+   return ret;
+
+   ret = spi_nor_wait_till_ready(nor);
+   if (ret)
+   return ret;
+
+
+   return spi_nor_default_setup(nor, hwcaps);
+}
+
+static void mt35xu512aba_default_init(struct spi_nor *nor)
+{
+   nor->params->octal_dtr_enable = spi_nor_micron_octal_dtr_enable;
+   nor->params->setup = mt35xu512aba_setup;
+}
+
+static void mt35xu512aba_post_sfdp_fixup(struct spi_nor *nor)
+{
+   /* Set the Fast Read settings. */
+   nor->params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
+   spi_nor_set_read_settings(>params->reads[SNOR_CMD_READ_8_8_8_DTR],
+ 0, 20, SPINOR_OP_MT_DTR_RD,
+ SNOR_PROTO_8_8_8_DTR);
+
+   nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
+
+   nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+   nor->params->rdsr_dummy = 8;
+   nor->params->rdsr_addr_nbytes = 0;
+}
+
+static struct spi_nor_fixups mt35xu512aba_fixups = {
+   .default_init = mt35xu512aba_default_init,
+   .post_sfdp = mt35xu512aba_post_sfdp_fixup,
+};
+
 static const struct flash_info micron_parts[] = {
{ "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512,
   SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
-  SPI_NOR_4B_OPCODES) },
+  SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_DTR_READ)
+   .fixups = _fixups},
{ "mt35xu02g", INFO(0x2c5b1c, 0, 128 * 1024, 2048,
SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
SPI_NOR_4B_OPCODES) },
-- 
2.26.2

Re: [rcu] 2f08469563: BUG:kernel_reboot-without-warning_in_boot_stage

2020-05-20 Thread Nick Desaulniers

On Tue, May 19, 2020 at 11:32 AM Marco Elver  wrote:
>
> This fixes the problem:
> https://lkml.kernel.org/r/20200519182459.87166-1-el...@google.com
>
> I suppose there are several things that happened that caused the above
> bisected changes to trigger this. Hard to say how exactly the above
> bisected changes caused this to manifest, because during early boot
> (while uninitialized) KASAN may just randomly enter kasan_report()
> before the branch (annotated with likely(), which is caught by the
> branch tracer) prevents it from actually generating a report. However,
> if it goes branch tracer -> KASAN -> branch tracers -> KASAN ..., then
> we crash. If I had to guess some combination of different code gen,
> different stack and/or data usage. So all the above bisected changes
> (AFAIK) were red herrings. :-)

Thanks for chasing to resolution.  Consider using a variable to store
a list of flags, as that code (before your patch) invokes the compiler
multiple times to answer the same question.
-- 
Thanks,
~Nick Desaulniers

[PATCH v6 17/19] mtd: spi-nor: core: expose spi_nor_default_setup() in core.h

Flashes might want to add a custom setup hook to configure the flash in
the proper mode for operation. But after that, they would still want to
run the default setup hook because it selects the read, program, and
erase operations. Since there is little point in repeating all that
code, expose the spi_nor_default_setup() in core.h to
manufacturer-specific files.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/core.c | 4 ++--
 drivers/mtd/spi-nor/core.h | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 63ab588299f4..30d9149fd17b 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2790,8 +2790,8 @@ static int spi_nor_select_erase(struct spi_nor *nor)
return 0;
 }
 
-static int spi_nor_default_setup(struct spi_nor *nor,
-const struct spi_nor_hwcaps *hwcaps)
+int spi_nor_default_setup(struct spi_nor *nor,
+ const struct spi_nor_hwcaps *hwcaps)
 {
struct spi_nor_flash_parameter *params = nor->params;
u32 ignored_mask, shared_mask;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 79ce952c0539..d37a9b1d111f 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -452,6 +452,9 @@ int spi_nor_post_bfpt_fixups(struct spi_nor *nor,
 const struct sfdp_bfpt *bfpt,
 struct spi_nor_flash_parameter *params);
 
+int spi_nor_default_setup(struct spi_nor *nor,
+ const struct spi_nor_hwcaps *hwcaps);
+
 static struct spi_nor __maybe_unused *mtd_to_spi_nor(struct mtd_info *mtd)
 {
return mtd->priv;
-- 
2.26.2

[PATCH v6 15/19] mtd: spi-nor: core: perform a Soft Reset on shutdown

Perform a Soft Reset on shutdown on flashes that support it so that the
flash can be reset to its initial state and any configurations made by
spi-nor (given that they're only done in volatile registers) will be
reset. This will hand back the flash in pristine state for any further
operations on it.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/core.c  | 42 +
 include/linux/mtd/spi-nor.h |  2 ++
 2 files changed, 44 insertions(+)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index a94376344be5..68559386f6f8 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -40,6 +40,9 @@
 
 #define SPI_NOR_MAX_ADDR_WIDTH 4
 
+#define SPI_NOR_SRST_SLEEP_MIN 200
+#define SPI_NOR_SRST_SLEEP_MAX 400
+
 /**
  * spi_nor_get_cmd_ext() - Get the command opcode extension based on the
  *extension type.
@@ -3201,6 +3204,41 @@ static int spi_nor_init(struct spi_nor *nor)
return 0;
 }
 
+static void spi_nor_soft_reset(struct spi_nor *nor)
+{
+   struct spi_mem_op op;
+   int ret;
+
+   op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 8),
+   SPI_MEM_OP_NO_DUMMY,
+   SPI_MEM_OP_NO_ADDR,
+   SPI_MEM_OP_NO_DATA);
+   spi_nor_spimem_setup_op(nor, , SNOR_PROTO_8_8_8_DTR);
+   ret = spi_mem_exec_op(nor->spimem, );
+   if (ret) {
+   dev_warn(nor->dev, "Software reset failed: %d\n", ret);
+   return;
+   }
+
+   op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 8),
+   SPI_MEM_OP_NO_DUMMY,
+   SPI_MEM_OP_NO_ADDR,
+   SPI_MEM_OP_NO_DATA);
+   spi_nor_spimem_setup_op(nor, , SNOR_PROTO_8_8_8_DTR);
+   ret = spi_mem_exec_op(nor->spimem, );
+   if (ret) {
+   dev_warn(nor->dev, "Software reset failed: %d\n", ret);
+   return;
+   }
+
+   /*
+* Software Reset is not instant, and the delay varies from flash to
+* flash. Looking at a few flashes, most range somewhere below 100
+* microseconds. So, sleep for a range of 200-400 us.
+*/
+   usleep_range(SPI_NOR_SRST_SLEEP_MIN, SPI_NOR_SRST_SLEEP_MAX);
+}
+
 /* mtd resume handler */
 static void spi_nor_resume(struct mtd_info *mtd)
 {
@@ -3220,6 +3258,10 @@ void spi_nor_restore(struct spi_nor *nor)
if (nor->addr_width == 4 && !(nor->flags & SNOR_F_4B_OPCODES) &&
nor->flags & SNOR_F_BROKEN_RESET)
nor->params->set_4byte_addr_mode(nor, false);
+
+   if (nor->info->flags & SPI_NOR_OCTAL_DTR_READ &&
+   nor->flags & SNOR_F_SOFT_RESET)
+   spi_nor_soft_reset(nor);
 }
 EXPORT_SYMBOL_GPL(spi_nor_restore);
 
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index d251a5d02be2..06884a188315 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -51,6 +51,8 @@
 #define SPINOR_OP_CLFSR0x50/* Clear flag status register */
 #define SPINOR_OP_RDEAR0xc8/* Read Extended Address 
Register */
 #define SPINOR_OP_WREAR0xc5/* Write Extended Address 
Register */
+#define SPINOR_OP_SRSTEN   0x66/* Software Reset Enable */
+#define SPINOR_OP_SRST 0x99/* Software Reset */
 
 /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
 #define SPINOR_OP_READ_4B  0x13/* Read data bytes (low frequency) */
-- 
2.26.2

[PATCH v6 16/19] mtd: spi-nor: core: disable Octal DTR mode on suspend.

On resume, the init procedure will be run that will re-enable it.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/core.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 68559386f6f8..63ab588299f4 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3239,6 +3239,23 @@ static void spi_nor_soft_reset(struct spi_nor *nor)
usleep_range(SPI_NOR_SRST_SLEEP_MIN, SPI_NOR_SRST_SLEEP_MAX);
 }
 
+/* mtd suspend handler */
+static int spi_nor_suspend(struct mtd_info *mtd)
+{
+   struct spi_nor *nor = mtd_to_spi_nor(mtd);
+   struct device *dev = nor->dev;
+   int ret;
+
+   /* Disable octal DTR mode if we enabled it. */
+   ret = spi_nor_octal_dtr_enable(nor, false);
+   if (ret) {
+   dev_err(dev, "suspend() failed\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 /* mtd resume handler */
 static void spi_nor_resume(struct mtd_info *mtd)
 {
@@ -3432,6 +3449,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
mtd->size = nor->params->size;
mtd->_erase = spi_nor_erase;
mtd->_read = spi_nor_read;
+   mtd->_suspend = spi_nor_suspend;
mtd->_resume = spi_nor_resume;
 
if (nor->params->locking_ops) {
-- 
2.26.2

[PATCH v6 13/19] mtd: spi-nor: sfdp: do not make invalid quad enable fatal

The Micron MT35XU512ABA flash does not support the quad enable bit. But
instead of programming the Quad Enable Require field to 000b ("Device
does not have a QE bit"), it is programmed to 111b ("Reserved").

While this is technically incorrect, it is not reason enough to abort
BFPT parsing. Instead, continue BFPT parsing assuming there is no quad
enable bit present.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/sfdp.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 052cabb52df9..9fd3d8d9a127 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -576,10 +576,6 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
 
/* Quad Enable Requirements. */
switch (bfpt.dwords[BFPT_DWORD(15)] & BFPT_DWORD15_QER_MASK) {
-   case BFPT_DWORD15_QER_NONE:
-   params->quad_enable = NULL;
-   break;
-
case BFPT_DWORD15_QER_SR2_BIT1_BUGGY:
/*
 * Writing only one byte to the Status Register has the
@@ -616,8 +612,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
params->quad_enable = spi_nor_sr2_bit1_quad_enable;
break;
 
+   case BFPT_DWORD15_QER_NONE:
default:
-   return -EINVAL;
+   params->quad_enable = NULL;
+   break;
}
 
/* Stop here if JESD216 rev B. */
-- 
2.26.2

[PATCH v6 14/19] mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPT

A Soft Reset sequence will return the flash to Power-on-Reset (POR)
state. It consists of two commands: Soft Reset Enable and Soft Reset.
Find out if the sequence is supported from BFPT DWORD 16.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/core.h | 1 +
 drivers/mtd/spi-nor/sfdp.c | 4 
 drivers/mtd/spi-nor/sfdp.h | 2 ++
 3 files changed, 7 insertions(+)

diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 6338d32a0d77..79ce952c0539 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -26,6 +26,7 @@ enum spi_nor_option_flags {
SNOR_F_HAS_SR_TB_BIT6   = BIT(11),
SNOR_F_HAS_4BIT_BP  = BIT(12),
SNOR_F_HAS_SR_BP3_BIT6  = BIT(13),
+   SNOR_F_SOFT_RESET   = BIT(14),
 };
 
 struct spi_nor_read_command {
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 9fd3d8d9a127..11109969dc3a 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -618,6 +618,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
break;
}
 
+   /* Soft Reset support. */
+   if (bfpt.dwords[BFPT_DWORD(16)] & BFPT_DWORD16_SOFT_RST)
+   nor->flags |= SNOR_F_SOFT_RESET;
+
/* Stop here if JESD216 rev B. */
if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, ,
diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
index e15e30796d62..d1d43ee09a0a 100644
--- a/drivers/mtd/spi-nor/sfdp.h
+++ b/drivers/mtd/spi-nor/sfdp.h
@@ -84,6 +84,8 @@ struct sfdp_bfpt {
 #define BFPT_DWORD15_QER_SR2_BIT1_NO_RD(0x4UL << 20)
 #define BFPT_DWORD15_QER_SR2_BIT1  (0x5UL << 20) /* Spansion */
 
+#define BFPT_DWORD16_SOFT_RST  BIT(12)
+
 #define BFPT_DWORD18_CMD_EXT_MASK  GENMASK(30, 29)
 #define BFPT_DWORD18_CMD_EXT_REP   (0x0UL << 29) /* Repeat */
 #define BFPT_DWORD18_CMD_EXT_INV   (0x1UL << 29) /* Invert */
-- 
2.26.2

[PATCH v6 12/19] mtd: spi-nor: core: enable octal DTR mode when possible

Allow flashes to specify a hook to enable octal DTR mode. Use this hook
whenever possible to get optimal transfer speeds.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/core.c | 35 +++
 drivers/mtd/spi-nor/core.h |  2 ++
 2 files changed, 37 insertions(+)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 5cb7e391cd29..a94376344be5 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3097,6 +3097,35 @@ static int spi_nor_init_params(struct spi_nor *nor)
return 0;
 }
 
+/** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
+ * @nor: pointer to a 'struct spi_nor'
+ * @enable:  whether to enable or disable Octal DTR
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_octal_dtr_enable(struct spi_nor *nor, bool enable)
+{
+   int ret;
+
+   if (!nor->params->octal_dtr_enable)
+   return 0;
+
+   if (!(nor->read_proto == SNOR_PROTO_8_8_8_DTR &&
+ nor->write_proto == SNOR_PROTO_8_8_8_DTR))
+   return 0;
+
+   ret = nor->params->octal_dtr_enable(nor, enable);
+   if (ret)
+   return ret;
+
+   if (enable)
+   nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
+   else
+   nor->reg_proto = SNOR_PROTO_1_1_1;
+
+   return 0;
+}
+
 /**
  * spi_nor_quad_enable() - enable Quad I/O if needed.
  * @nor:pointer to a 'struct spi_nor'
@@ -3136,6 +3165,12 @@ static int spi_nor_init(struct spi_nor *nor)
 {
int err;
 
+   err = spi_nor_octal_dtr_enable(nor, true);
+   if (err) {
+   dev_dbg(nor->dev, "octal mode not supported\n");
+   return err;
+   }
+
err = spi_nor_quad_enable(nor);
if (err) {
dev_dbg(nor->dev, "quad mode not supported\n");
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 7e6df8322da0..6338d32a0d77 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -203,6 +203,7 @@ struct spi_nor_locking_ops {
  *  higher index in the array, the higher priority.
  * @erase_map: the erase map parsed from the SFDP Sector Map Parameter
  *  Table.
+ * @octal_dtr_enable:  enables SPI NOR octal DTR mode.
  * @quad_enable:   enables SPI NOR quad mode.
  * @set_4byte_addr_mode: puts the SPI NOR in 4 byte addressing mode.
  * @convert_addr:  converts an absolute address into something the flash
@@ -226,6 +227,7 @@ struct spi_nor_flash_parameter {
 
struct spi_nor_erase_maperase_map;
 
+   int (*octal_dtr_enable)(struct spi_nor *nor, bool enable);
int (*quad_enable)(struct spi_nor *nor);
int (*set_4byte_addr_mode)(struct spi_nor *nor, bool enable);
u32 (*convert_addr)(struct spi_nor *nor, u32 addr);
-- 
2.26.2

[PATCH v6 01/19] spi: spi-mem: allow specifying whether an op is DTR or not

Each phase is given a separate 'dtr' field so mixed protocols like
4S-4D-4D can be supported.

Signed-off-by: Pratyush Yadav 
---
 drivers/spi/spi-mem.c   | 3 +++
 include/linux/spi/spi-mem.h | 8 
 2 files changed, 11 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 9a86cc27fcc0..93e255287ab9 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -156,6 +156,9 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
   op->data.dir == SPI_MEM_DATA_OUT))
return false;
 
+   if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+   return false;
+
return true;
 }
 EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index af9ff2f0f1b2..e3dcb956bf61 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -71,9 +71,11 @@ enum spi_mem_data_dir {
  * struct spi_mem_op - describes a SPI memory operation
  * @cmd.buswidth: number of IO lines used to transmit the command
  * @cmd.opcode: operation opcode
+ * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
  * @addr.nbytes: number of address bytes to send. Can be zero if the operation
  *  does not need to send an address
  * @addr.buswidth: number of IO lines used to transmit the address cycles
+ * @addr.dtr: whether the address should be sent in DTR mode or not
  * @addr.val: address value. This value is always sent MSB first on the bus.
  *   Note that only @addr.nbytes are taken into account in this
  *   address value, so users should make sure the value fits in the
@@ -81,7 +83,9 @@ enum spi_mem_data_dir {
  * @dummy.nbytes: number of dummy bytes to send after an opcode or address. Can
  *   be zero if the operation does not require dummy bytes
  * @dummy.buswidth: number of IO lanes used to transmit the dummy bytes
+ * @dummy.dtr: whether the dummy bytes should be sent in DTR mode or not
  * @data.buswidth: number of IO lanes used to send/receive the data
+ * @data.dtr: whether the data should be sent in DTR mode or not
  * @data.dir: direction of the transfer
  * @data.nbytes: number of data bytes to send/receive. Can be zero if the
  *  operation does not involve transferring data
@@ -91,22 +95,26 @@ enum spi_mem_data_dir {
 struct spi_mem_op {
struct {
u8 buswidth;
+   u8 dtr : 1;
u8 opcode;
} cmd;
 
struct {
u8 nbytes;
u8 buswidth;
+   u8 dtr : 1;
u64 val;
} addr;
 
struct {
u8 nbytes;
u8 buswidth;
+   u8 dtr : 1;
} dummy;
 
struct {
u8 buswidth;
+   u8 dtr : 1;
enum spi_mem_data_dir dir;
unsigned int nbytes;
union {
-- 
2.26.2

[PATCH v6 05/19] mtd: spi-nor: add support for DTR protocol

Double Transfer Rate (DTR) is SPI protocol in which data is transferred
on each clock edge as opposed to on each clock cycle. Make
framework-level changes to allow supporting flashes in DTR mode.

Right now, mixed DTR modes are not supported. So, for example a mode
like 4S-4D-4D will not work. All phases need to be either DTR or STR.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/core.c  | 305 
 drivers/mtd/spi-nor/core.h  |   6 +
 drivers/mtd/spi-nor/sfdp.c  |   9 +-
 include/linux/mtd/spi-nor.h |  51 --
 4 files changed, 295 insertions(+), 76 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 1ab4386a099a..388e695e763f 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -40,6 +40,76 @@
 
 #define SPI_NOR_MAX_ADDR_WIDTH 4
 
+/**
+ * spi_nor_get_cmd_ext() - Get the command opcode extension based on the
+ *extension type.
+ * @nor:   pointer to a 'struct spi_nor'
+ * @op:pointer to the 'struct spi_mem_op' whose 
properties
+ * need to be initialized.
+ *
+ * Right now, only "repeat" and "invert" are supported.
+ *
+ * Return: The opcode extension.
+ */
+static u8 spi_nor_get_cmd_ext(const struct spi_nor *nor,
+ const struct spi_mem_op *op)
+{
+   switch (nor->cmd_ext_type) {
+   case SPI_NOR_EXT_INVERT:
+   return ~op->cmd.opcode;
+
+   case SPI_NOR_EXT_REPEAT:
+   return op->cmd.opcode;
+
+   default:
+   dev_err(nor->dev, "Unknown command extension type\n");
+   return 0;
+   }
+}
+
+/**
+ * spi_nor_spimem_setup_op() - Set up common properties of a spi-mem op.
+ * @nor:   pointer to a 'struct spi_nor'
+ * @op:pointer to the 'struct spi_mem_op' whose 
properties
+ * need to be initialized.
+ * @proto: the protocol from which the properties need to be set.
+ */
+void spi_nor_spimem_setup_op(const struct spi_nor *nor,
+struct spi_mem_op *op,
+const enum spi_nor_protocol proto)
+{
+   u8 ext;
+
+   op->cmd.buswidth = spi_nor_get_protocol_inst_nbits(proto);
+
+   if (op->addr.nbytes)
+   op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto);
+
+   if (op->dummy.nbytes)
+   op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto);
+
+   if (op->data.nbytes)
+   op->data.buswidth = spi_nor_get_protocol_data_nbits(proto);
+
+   if (spi_nor_protocol_is_dtr(proto)) {
+   /*
+* spi-mem supports mixed DTR modes, but right now we can only
+* have all phases either DTR or STR. IOW, spi-mem can have
+* something like 4S-4D-4D, but spi-nor can't. So, set all 4
+* phases to either DTR or STR.
+*/
+   op->cmd.dtr = op->addr.dtr = op->dummy.dtr
+  = op->data.dtr = true;
+
+   /* 2 bytes per clock cycle in DTR mode. */
+   op->dummy.nbytes *= 2;
+
+   ext = spi_nor_get_cmd_ext(nor, op);
+   op->cmd.opcode = (op->cmd.opcode << 8) | ext;
+   op->cmd.nbytes = 2;
+   }
+}
+
 /**
  * spi_nor_spimem_bounce() - check if a bounce buffer is needed for the data
  *   transfer
@@ -104,14 +174,12 @@ static ssize_t spi_nor_spimem_read_data(struct spi_nor 
*nor, loff_t from,
ssize_t nbytes;
int error;
 
-   /* get transfer protocols. */
-   op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->read_proto);
-   op.addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->read_proto);
-   op.dummy.buswidth = op.addr.buswidth;
-   op.data.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
+   spi_nor_spimem_setup_op(nor, , nor->read_proto);
 
/* convert the dummy cycles to the number of bytes */
op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
+   if (spi_nor_protocol_is_dtr(nor->read_proto))
+   op.dummy.nbytes *= 2;
 
usebouncebuf = spi_nor_spimem_bounce(nor, );
 
@@ -169,13 +237,11 @@ static ssize_t spi_nor_spimem_write_data(struct spi_nor 
*nor, loff_t to,
ssize_t nbytes;
int error;
 
-   op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->write_proto);
-   op.addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->write_proto);
-   op.data.buswidth = spi_nor_get_protocol_data_nbits(nor->write_proto);
-
if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
op.addr.nbytes = 0;
 
+   spi_nor_spimem_setup_op(nor, , nor->write_proto);
+
if (spi_nor_spimem_bounce(nor, ))
memcpy(nor->bouncebuf, buf, op.data.nbytes);
 
@@ -227,10 +293,16 @@ int

[PATCH v6 10/19] mtd: spi-nor: core: use dummy cycle and address width info from SFDP

The xSPI Profile 1.0 table specifies how many dummy cycles and address
bytes are needed for the Read Status Register command in octal DTR mode.
Use that information to send the correct Read SR command.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/core.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 642e3c07acf9..2ad248140b6c 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -357,6 +357,8 @@ int spi_nor_write_disable(struct spi_nor *nor)
 static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
 {
int ret;
+   u8 addr_bytes = nor->params->rdsr_addr_nbytes;
+   u8 dummy = nor->params->rdsr_dummy;
 
if (nor->spimem) {
struct spi_mem_op op =
@@ -365,10 +367,21 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
   SPI_MEM_OP_NO_DUMMY,
   SPI_MEM_OP_DATA_IN(1, sr, 1));
 
+   if (spi_nor_protocol_is_dtr(nor->reg_proto)) {
+   op.addr.nbytes = addr_bytes;
+   op.addr.val = 0;
+   op.dummy.nbytes = dummy;
+   }
+
+   spi_nor_spimem_setup_op(nor, , nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, );
} else {
-   ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDSR,
-   sr, 1);
+   if (spi_nor_protocol_is_dtr(nor->reg_proto))
+   ret = -ENOTSUPP;
+   else
+   ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDSR,
+   sr, 1);
}
 
if (ret)
@@ -388,6 +401,8 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
 static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
 {
int ret;
+   u8 addr_bytes = nor->params->rdsr_addr_nbytes;
+   u8 dummy = nor->params->rdsr_dummy;
 
if (nor->spimem) {
struct spi_mem_op op =
@@ -396,6 +411,12 @@ static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
   SPI_MEM_OP_NO_DUMMY,
   SPI_MEM_OP_DATA_IN(1, fsr, 1));
 
+   if (spi_nor_protocol_is_dtr(nor->reg_proto)) {
+   op.addr.nbytes = addr_bytes;
+   op.addr.val = 0;
+   op.dummy.nbytes = dummy;
+   }
+
spi_nor_spimem_setup_op(nor, , nor->reg_proto);
 
ret = spi_mem_exec_op(nor->spimem, );
-- 
2.26.2

[PATCH v6 07/19] mtd: spi-nor: sfdp: prepare BFPT parsing for JESD216 rev D

JESD216 rev D makes BFPT 20 DWORDs. Update the BFPT size define to
reflect that.

The check for rev A or later compared the BFPT header length with the
maximum BFPT length, BFPT_DWORD_MAX. Since BFPT_DWORD_MAX was 16, and so
was the BFPT length for both rev A and B, this check worked fine. But
now, since BFPT_DWORD_MAX is 20, it means this check will also stop BFPT
parsing for rev A or B, since their length is 16.

So, instead check for BFPT_DWORD_MAX_JESD216 to stop BFPT parsing for
the first JESD216 version, and check for BFPT_DWORD_MAX_JESD216B for the
next two versions.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/sfdp.c | 7 ++-
 drivers/mtd/spi-nor/sfdp.h | 5 +++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 5cecc4ba2141..96960f2f3d7a 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -549,7 +549,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
  SNOR_ERASE_TYPE_MASK;
 
/* Stop here if not JESD216 rev A or later. */
-   if (bfpt_header->length < BFPT_DWORD_MAX)
+   if (bfpt_header->length == BFPT_DWORD_MAX_JESD216)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, ,
params);
 
@@ -605,6 +605,11 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
return -EINVAL;
}
 
+   /* Stop here if JESD216 rev B. */
+   if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
+   return spi_nor_post_bfpt_fixups(nor, bfpt_header, ,
+   params);
+
return spi_nor_post_bfpt_fixups(nor, bfpt_header, , params);
 }
 
diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
index e0a8ded04890..f8198af43a63 100644
--- a/drivers/mtd/spi-nor/sfdp.h
+++ b/drivers/mtd/spi-nor/sfdp.h
@@ -10,11 +10,11 @@
 /* Basic Flash Parameter Table */
 
 /*
- * JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs.
+ * JESD216 rev D defines a Basic Flash Parameter Table of 20 DWORDs.
  * They are indexed from 1 but C arrays are indexed from 0.
  */
 #define BFPT_DWORD(i)  ((i) - 1)
-#define BFPT_DWORD_MAX 16
+#define BFPT_DWORD_MAX 20
 
 struct sfdp_bfpt {
u32 dwords[BFPT_DWORD_MAX];
@@ -22,6 +22,7 @@ struct sfdp_bfpt {
 
 /* The first version of JESD216 defined only 9 DWORDs. */
 #define BFPT_DWORD_MAX_JESD216 9
+#define BFPT_DWORD_MAX_JESD216B16
 
 /* 1st DWORD. */
 #define BFPT_DWORD1_FAST_READ_1_1_2BIT(16)
-- 
2.26.2

[PATCH v6 02/19] spi: atmel-quadspi: reject DTR ops

Double Transfer Rate (DTR) ops are added in spi-mem. But this controller
doesn't support DTR transactions. Since we don't use the default
supports_op(), which rejects all DTR ops, do that explicitly in our
supports_op().

Signed-off-by: Pratyush Yadav 
---
 drivers/spi/atmel-quadspi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
index cb44d1e169aa..4a29fa7ebdac 100644
--- a/drivers/spi/atmel-quadspi.c
+++ b/drivers/spi/atmel-quadspi.c
@@ -285,6 +285,10 @@ static bool atmel_qspi_supports_op(struct spi_mem *mem,
op->dummy.nbytes == 0)
return false;
 
+   /* DTR ops not supported. */
+   if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+   return false;
+
return true;
 }
 
-- 
2.26.2

[PATCH v6 09/19] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table

This table is indication that the flash is xSPI compliant and hence
supports octal DTR mode. Extract information like the fast read opcode,
dummy cycles, the number of dummy cycles needed for a Read Status
Register command, and the number of address bytes needed for a Read
Status Register command.

We don't know what speed the controller is running at. Find the fast
read dummy cycles for the fastest frequency the flash can run at to be
sure we are never short of dummy cycles. If nothing is available,
default to 20. Flashes that use a different value should update it in
their fixup hooks.

Since we want to set read settings, expose spi_nor_set_read_settings()
in core.h.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/core.c |  2 +-
 drivers/mtd/spi-nor/core.h | 10 
 drivers/mtd/spi-nor/sfdp.c | 99 ++
 3 files changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 388e695e763f..642e3c07acf9 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2355,7 +2355,7 @@ static int spi_nor_check(struct spi_nor *nor)
return 0;
 }
 
-static void
+void
 spi_nor_set_read_settings(struct spi_nor_read_command *read,
  u8 num_mode_clocks,
  u8 num_wait_states,
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index de1e3917889f..7e6df8322da0 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -192,6 +192,9 @@ struct spi_nor_locking_ops {
  *
  * @size:  the flash memory density in bytes.
  * @page_size: the page size of the SPI NOR flash memory.
+ * @rdsr_dummy:dummy cycles needed for Read Status Register 
command.
+ * @rdsr_addr_nbytes:  dummy address bytes needed for Read Status Register
+ * command.
  * @hwcaps:describes the read and page program hardware
  * capabilities.
  * @reads: read capabilities ordered by priority: the higher index
@@ -214,6 +217,8 @@ struct spi_nor_locking_ops {
 struct spi_nor_flash_parameter {
u64 size;
u32 page_size;
+   u8  rdsr_dummy;
+   u8  rdsr_addr_nbytes;
 
struct spi_nor_hwcaps   hwcaps;
struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
@@ -424,6 +429,11 @@ ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, 
size_t len,
 
 int spi_nor_hwcaps_read2cmd(u32 hwcaps);
 u8 spi_nor_convert_3to4_read(u8 opcode);
+void spi_nor_set_read_settings(struct spi_nor_read_command *read,
+ u8 num_mode_clocks,
+ u8 num_wait_states,
+ u8 opcode,
+ enum spi_nor_protocol proto);
 void spi_nor_set_pp_settings(struct spi_nor_pp_command *pp, u8 opcode,
 enum spi_nor_protocol proto);
 
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index ab086aa4746f..052cabb52df9 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -4,12 +4,15 @@
  * Copyright (C) 2014, Freescale Semiconductor, Inc.
  */
 
+#include 
 #include 
 #include 
 #include 
 
 #include "core.h"
 
+#define ROUND_UP_TO(x, y)  (((x) + (y) - 1) / (y) * (y))
+
 #define SFDP_PARAM_HEADER_ID(p)(((p)->id_msb << 8) | (p)->id_lsb)
 #define SFDP_PARAM_HEADER_PTP(p) \
(((p)->parameter_table_pointer[2] << 16) | \
@@ -19,12 +22,14 @@
 #define SFDP_BFPT_ID   0xff00  /* Basic Flash Parameter Table */
 #define SFDP_SECTOR_MAP_ID 0xff81  /* Sector Map Table */
 #define SFDP_4BAIT_ID  0xff84  /* 4-byte Address Instruction Table */
+#define SFDP_PROFILE1_ID   0xff05  /* xSPI Profile 1.0 table. */
 
 #define SFDP_SIGNATURE 0x50444653U
 #define SFDP_JESD216_MAJOR 1
 #define SFDP_JESD216_MINOR 0
 #define SFDP_JESD216A_MINOR5
 #define SFDP_JESD216B_MINOR6
+#define SFDP_JESD216D_MINOR8
 
 struct sfdp_header {
u32 signature; /* Ox50444653U <=> "SFDP" */
@@ -70,6 +75,16 @@ struct sfdp_bfpt_erase {
u32 shift;
 };
 
+/* xSPI Profile 1.0 table (from JESD216D.01). */
+#define PROFILE1_DWORD1_RD_FAST_CMDGENMASK(15, 8)
+#define PROFILE1_DWORD1_RDSR_DUMMY BIT(28)
+#define PROFILE1_DWORD1_RDSR_ADDR_BYTESBIT(29)
+#define PROFILE1_DWORD4_DUMMY_200MHZ   GENMASK(11, 7)
+#define PROFILE1_DWORD5_DUMMY_166MHZ   GENMASK(31, 27)
+#define PROFILE1_DWORD5_DUMMY_133MHZ   GENMASK(21, 17)
+#define PROFILE1_DWORD5_DUMMY_100MHZ   GENMASK(11, 7)
+#define PROFILE1_DUMMY_DEFAULT 20
+
 #define SMPT_CMD_ADDRESS_LEN_MASK  GENMASK(23, 22)
 #define SMPT_CMD_ADDRESS_LEN_0 (0x0UL << 22)
 #define

[PATCH v6 11/19] mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR mode

Some controllers, like the cadence qspi controller, have trouble reading
only 1 byte in DTR mode. So, do 2 byte reads for SR and FSR commands in
DTR mode, and then discard the second byte.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/core.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 2ad248140b6c..5cb7e391cd29 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -350,7 +350,7 @@ int spi_nor_write_disable(struct spi_nor *nor)
  * spi_nor_read_sr() - Read the Status Register.
  * @nor:   pointer to 'struct spi_nor'.
  * @sr:pointer to a DMA-able buffer where the value of the
- *  Status Register will be written.
+ *  Status Register will be written. Should be at least 2 bytes.
  *
  * Return: 0 on success, -errno otherwise.
  */
@@ -371,6 +371,11 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
op.addr.nbytes = addr_bytes;
op.addr.val = 0;
op.dummy.nbytes = dummy;
+   /*
+* We don't want to read only one byte in DTR mode. So,
+* read 2 and then discard the second byte.
+*/
+   op.data.nbytes = 2;
}
 
spi_nor_spimem_setup_op(nor, , nor->reg_proto);
@@ -394,7 +399,8 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
  * spi_nor_read_fsr() - Read the Flag Status Register.
  * @nor:   pointer to 'struct spi_nor'
  * @fsr:   pointer to a DMA-able buffer where the value of the
- *  Flag Status Register will be written.
+ *  Flag Status Register will be written. Should be at least 2
+ *  bytes.
  *
  * Return: 0 on success, -errno otherwise.
  */
@@ -415,6 +421,11 @@ static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
op.addr.nbytes = addr_bytes;
op.addr.val = 0;
op.dummy.nbytes = dummy;
+   /*
+* We don't want to read only one byte in DTR mode. So,
+* read 2 and then discard the second byte.
+*/
+   op.data.nbytes = 2;
}
 
spi_nor_spimem_setup_op(nor, , nor->reg_proto);
-- 
2.26.2

[PATCH v6 08/19] mtd: spi-nor: sfdp: get command opcode extension type from BFPT

Some devices in DTR mode expect an extra command byte called the
extension. The extension can either be same as the opcode, bitwise
inverse of the opcode, or another additional byte forming a 16-byte
opcode. Get the extension type from the BFPT. For now, only flashes with
"repeat" and "inverse" extensions are supported.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/sfdp.c | 17 +
 drivers/mtd/spi-nor/sfdp.h |  6 ++
 2 files changed, 23 insertions(+)

diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 96960f2f3d7a..ab086aa4746f 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -609,6 +609,23 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, ,
params);
+   /* 8D-8D-8D command extension. */
+   switch (bfpt.dwords[BFPT_DWORD(18)] & BFPT_DWORD18_CMD_EXT_MASK) {
+   case BFPT_DWORD18_CMD_EXT_REP:
+   nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+   break;
+
+   case BFPT_DWORD18_CMD_EXT_INV:
+   nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
+   break;
+
+   case BFPT_DWORD18_CMD_EXT_RES:
+   return -EINVAL;
+
+   case BFPT_DWORD18_CMD_EXT_16B:
+   dev_err(nor->dev, "16-bit opcodes not supported\n");
+   return -ENOTSUPP;
+   }
 
return spi_nor_post_bfpt_fixups(nor, bfpt_header, , params);
 }
diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
index f8198af43a63..e15e30796d62 100644
--- a/drivers/mtd/spi-nor/sfdp.h
+++ b/drivers/mtd/spi-nor/sfdp.h
@@ -84,6 +84,12 @@ struct sfdp_bfpt {
 #define BFPT_DWORD15_QER_SR2_BIT1_NO_RD(0x4UL << 20)
 #define BFPT_DWORD15_QER_SR2_BIT1  (0x5UL << 20) /* Spansion */
 
+#define BFPT_DWORD18_CMD_EXT_MASK  GENMASK(30, 29)
+#define BFPT_DWORD18_CMD_EXT_REP   (0x0UL << 29) /* Repeat */
+#define BFPT_DWORD18_CMD_EXT_INV   (0x1UL << 29) /* Invert */
+#define BFPT_DWORD18_CMD_EXT_RES   (0x2UL << 29) /* Reserved */
+#define BFPT_DWORD18_CMD_EXT_16B   (0x3UL << 29) /* 16-bit opcode 
*/
+
 struct sfdp_parameter_header {
u8  id_lsb;
u8  minor;
-- 
2.26.2

[PATCH v6 04/19] spi: spi-mem: allow specifying a command's extension

In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
the "command extension". There can be 3 types of extensions in xSPI:
repeat, invert, and hex. When the extension type is "repeat", the same
opcode is sent twice. When it is "invert", the second byte is the
inverse of the opcode. When it is "hex" an additional opcode byte based
is sent with the command whose value can be anything.

So, make opcode a 16-bit value and add a 'nbytes', similar to how
multiple address widths are handled.

Signed-off-by: Pratyush Yadav 
---
 include/linux/spi/spi-mem.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index e3dcb956bf61..731bb64c6ba6 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -69,6 +69,8 @@ enum spi_mem_data_dir {
 
 /**
  * struct spi_mem_op - describes a SPI memory operation
+ * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
+ * sent MSB-first.
  * @cmd.buswidth: number of IO lines used to transmit the command
  * @cmd.opcode: operation opcode
  * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
@@ -94,9 +96,10 @@ enum spi_mem_data_dir {
  */
 struct spi_mem_op {
struct {
+   u8 nbytes;
u8 buswidth;
u8 dtr : 1;
-   u8 opcode;
+   u16 opcode;
} cmd;
 
struct {
-- 
2.26.2

[PATCH] mm, memcg: unify reclaim retry limits with page allocator

2020-05-20 Thread Chris Down

Reclaim retries have been set to 5 since the beginning of time in
66e1707bc346 ("Memory controller: add per cgroup LRU and reclaim").
However, we now have a generally agreed-upon standard for page reclaim:
MAX_RECLAIM_RETRIES (currently 16), added many years later in
0a0337e0d1d1 ("mm, oom: rework oom detection").

In the absence of a compelling reason to declare an OOM earlier in memcg
context than page allocator context, it seems reasonable to supplant
MEM_CGROUP_RECLAIM_RETRIES with MAX_RECLAIM_RETRIES, making the page
allocator and memcg internals more similar in semantics when reclaim
fails to produce results, avoiding premature OOMs or throttling.

Signed-off-by: Chris Down 
Cc: Andrew Morton 
Cc: Johannes Weiner 
Cc: Michal Hocko 
---
 mm/memcontrol.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b040951ccd6b..d3b23c57bed4 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -73,9 +73,6 @@ EXPORT_SYMBOL(memory_cgrp_subsys);
 
 struct mem_cgroup *root_mem_cgroup __read_mostly;
 
-/* The number of times we should retry reclaim failures before giving up. */
-#define MEM_CGROUP_RECLAIM_RETRIES 5
-
 /* Socket memory accounting disabled? */
 static bool cgroup_memory_nosocket;
 
@@ -2386,7 +2383,7 @@ void mem_cgroup_handle_over_high(void)
unsigned long pflags;
unsigned long nr_reclaimed;
unsigned int nr_pages = current->memcg_nr_pages_over_high;
-   int nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
+   int nr_retries = MAX_RECLAIM_RETRIES;
struct mem_cgroup *memcg;
 
if (likely(!nr_pages))
@@ -2438,7 +2435,7 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t 
gfp_mask,
  unsigned int nr_pages)
 {
unsigned int batch = max(MEMCG_CHARGE_BATCH, nr_pages);
-   int nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
+   int nr_retries = MAX_RECLAIM_RETRIES;
struct mem_cgroup *mem_over_limit;
struct page_counter *counter;
unsigned long nr_reclaimed;
@@ -2557,7 +2554,7 @@ static int try_charge(struct mem_cgroup *memcg, gfp_t 
gfp_mask,
   get_order(nr_pages * PAGE_SIZE));
switch (oom_status) {
case OOM_SUCCESS:
-   nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
+   nr_retries = MAX_RECLAIM_RETRIES;
goto retry;
case OOM_FAILED:
goto force;
@@ -3168,7 +3165,7 @@ static inline bool memcg_has_children(struct mem_cgroup 
*memcg)
  */
 static int mem_cgroup_force_empty(struct mem_cgroup *memcg)
 {
-   int nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
+   int nr_retries = MAX_RECLAIM_RETRIES;
 
/* we call try-to-free pages for make this cgroup empty */
lru_add_drain_all();
@@ -6001,7 +5998,7 @@ static ssize_t memory_high_write(struct kernfs_open_file 
*of,
 char *buf, size_t nbytes, loff_t off)
 {
struct mem_cgroup *memcg = mem_cgroup_from_css(of_css(of));
-   unsigned int nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
+   unsigned int nr_retries = MAX_RECLAIM_RETRIES;
bool drained = false;
unsigned long high;
int err;
@@ -6049,7 +6046,7 @@ static ssize_t memory_max_write(struct kernfs_open_file 
*of,
char *buf, size_t nbytes, loff_t off)
 {
struct mem_cgroup *memcg = mem_cgroup_from_css(of_css(of));
-   unsigned int nr_reclaims = MEM_CGROUP_RECLAIM_RETRIES;
+   unsigned int nr_reclaims = MAX_RECLAIM_RETRIES;
bool drained = false;
unsigned long max;
int err;
-- 
2.26.2

[PATCH v6 06/19] mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths

JESD216D.01 says that when the address width can be 3 or 4, it defaults
to 3 and enters 4-byte mode when given the appropriate command. So, when
we see a configurable width, default to 3 and let flash that default to
4 change it in a post-bfpt fixup.

This fixes SMPT parsing for flashes with configurable address width. If
the SMPT descriptor advertises variable address width, we use
nor->addr_width as the address width. But since it was not set to any
value from the SFDP table, the read command uses an address width of 0,
resulting in an incorrect read being issued.

Signed-off-by: Pratyush Yadav 
---
 drivers/mtd/spi-nor/sfdp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index f917631c8110..5cecc4ba2141 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -460,6 +460,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
/* Number of address bytes. */
switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) {
case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY:
+   case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
nor->addr_width = 3;
break;
 
-- 
2.26.2

[PATCH v6 00/19] mtd: spi-nor: add xSPI Octal DTR support

Hi,

This series adds support for octal DTR flashes in the spi-nor framework,
and then adds hooks for the Cypress Semper and Mircom Xcella flashes to
allow running them in octal DTR mode. This series assumes that the flash
is handed to the kernel in Legacy SPI mode.

Tested on TI J721e EVM with 1-bit ECC on the Cypress flash.

Changes in v6:
- Instead of hard-coding 8D-8D-8D Fast Read dummy cycles to 20, find
  them out from the Profile 1.0 table.

Changes in v5:
- Do not enable stateful X-X-X modes if the reset line is broken.

- Instead of setting SNOR_READ_HWCAPS_8_8_8_DTR from Profile 1.0 table
  parsing, do it in spi_nor_info_init_params() instead based on the
  SPI_NOR_OCTAL_DTR_READ flag instead.

- Set SNOR_HWCAPS_PP_8_8_8_DTR in s28hs post_sfdp hook since this
  capability is no longer set in Profile 1.0 parsing.

- Instead of just checking for spi_nor_get_protocol_width() in
  spi_nor_octal_dtr_enable(), make sure the protocol is
  SNOR_PROTO_8_8_8_DTR since get_protocol_width() only cares about data
  width.

- Drop flag SPI_NOR_SOFT_RESET. Instead, discover soft reset capability
  via BFPT.

- Do not make an invalid Quad Enable BFPT field a fatal error. Silently
  ignore it by assuming no quad enable bit is present.

- Set dummy cycles for Cypress Semper flash to 24 instead of 20. This
  allows for 200MHz operation in 8D mode compared to the 166MHz with 20.

- Rename spi_nor_cypress_octal_enable() to
  spi_nor_cypress_octal_dtr_enable().

- Update spi-mtk-nor.c to reject DTR ops since it doesn't call
  spi_mem_default_supports_op().

Changes in v4:
- Refactor the series to use the new spi-nor framework with the
  manufacturer-specific bits separated from the core.

- Add support for Micron MT35XU512ABA.

- Use cmd.nbytes as the criteria of whether the data phase exists or not
  instead of cmd.buf.in || cmd.buf.out in spi_nor_spimem_setup_op().

- Update Read FSR to use the same dummy cycles and address width as Read
  SR.

- Fix BFPT parsing stopping too early for JESD216 rev B flashes.

- Use 2 byte reads for Read SR and FSR commands in DTR mode.

Changes in v3:
- Drop the DT properties "spi-rx-dtr" and "spi-tx-dtr". Instead, if
  later a need is felt to disable DTR in case someone has a board with
  Octal DTR capable flash but does not support DTR transactions for some
  reason, a property like "spi-no-dtr" can be added.

- Remove mode bits SPI_RX_DTR and SPI_TX_DTR.

- Remove the Cadence Quadspi controller patch to un-block this series. I
  will submit it as a separate patch.

- Rebase on latest 'master' and fix merge conflicts.

- Update read and write dirmap templates to use DTR.

- Rename 'is_dtr' to 'dtr'.

- Make 'dtr' a bitfield.

- Reject DTR ops in spi_mem_default_supports_op().

- Update atmel-quadspi to reject DTR ops. All other controller drivers
  call spi_mem_default_supports_op() so they will automatically reject
  DTR ops.

- Add support for both enabling and disabling DTR modes.

- Perform a Software Reset on flashes that support it when shutting
  down.

- Disable Octal DTR mode on suspend, and re-enable it on resume.

- Drop enum 'spi_mem_cmd_ext' and make command opcode u16 instead.
  Update spi-nor to use the 2-byte command instead of the command
  extension. Since we still need a "extension type", mode that enum to
  spi-nor and name it 'spi_nor_cmd_ext'.

- Default variable address width to 3 to fix SMPT parsing.

- Drop non-volatile change to uniform sector mode and rely on parsing
  SMPT.

Changes in v2:
- Add DT properties "spi-rx-dtr" and "spi-tx-dtr" to allow expressing
  DTR capabilities.

- Set the mode bits SPI_RX_DTR and SPI_TX_DTR when we discover the DT
  properties "spi-rx-dtr" and spi-tx-dtr".

- spi_nor_cypress_octal_enable() was updating nor->params.read[] with
  the intention of setting the correct number of dummy cycles. But this
  function is called _after_ selecting the read so setting
  nor->params.read[] will have no effect. So, update nor->read_dummy
  directly.

- Fix spi_nor_spimem_check_readop() and spi_nor_spimem_check_pp()
  passing nor->read_proto and nor->write_proto to
  spi_nor_spimem_setup_op() instead of read->proto and pp->proto
  respectively.

- Move the call to cqspi_setup_opcode_ext() inside cqspi_enable_dtr().
  This avoids repeating the 'if (f_pdata->is_dtr)
  cqspi_setup_opcode_ext()...` snippet multiple times.

- Call the default 'supports_op()' from cqspi_supports_mem_op(). This
  makes sure the buswidth requirements are also enforced along with the
  DTR requirements.

- Drop the 'is_dtr' argument from spi_check_dtr_req(). We only call it
  when a phase is DTR so it is redundant.

Pratyush Yadav (19):
  spi: spi-mem: allow specifying whether an op is DTR or not
  spi: atmel-quadspi: reject DTR ops
  spi: spi-mtk-nor: reject DTR ops
  spi: spi-mem: allow specifying a command's extension
  mtd: spi-nor: add support for DTR protocol
  mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths
  mtd: spi-nor: sfdp:

[PATCH v6 03/19] spi: spi-mtk-nor: reject DTR ops

Double Transfer Rate (DTR) ops are added in spi-mem. But this controller
doesn't support DTR transactions. Since we don't use the default
supports_op(), which rejects all DTR ops, do that explicitly in our
supports_op().

Signed-off-by: Pratyush Yadav 
---
 drivers/spi/spi-mtk-nor.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index 7bc302b50396..7015dccedf00 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -211,6 +211,10 @@ static bool mtk_nor_supports_op(struct spi_mem *mem,
if (op->cmd.buswidth != 1)
return false;
 
+   /* DTR ops not supported. */
+   if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+   return false;
+
if ((op->addr.nbytes == 3) || (op->addr.nbytes == 4)) {
if ((op->data.dir == SPI_MEM_DATA_IN) && mtk_nor_match_read(op))
return true;
-- 
2.26.2

Re: Re: [RFC PATCH] i2c: at91: Fix pinmux after devm_gpiod_get() for bus recovery

2020-05-20 Thread Wolfram Sang


> > This will do for 5.7. For 5.8 or 5.9, I can imagine to take the two
> > pinctrl_state pointers into bus_recovery_info and handle all this in the
> > core. I will try this later this week if noone is super-eager to try it
> > out before.
> > 
> 
> By 'all this' you mean to move the entire function in the core, right? 
> Having just these two pointers bus_recinovery_info won't help much. I 
> can try it, if you haven't already started...

I mean to add those two pointers to bus_recinovery_info and if they are
populated, then the I2C core is doing the necessary magic (or maybe just
the pinctrl handle and assume the states have fixed names?). Russell
just sent patches to add it to the PXA driver, so we could now double
check how much could be factored out.

I haven't started yet, let's keep in touch who started first :)



signature.asc
Description: PGP signature

[PATCH v2] perf config: Add stat.big-num support

2020-05-20 Thread Paul A. Clarke

From: "Paul A. Clarke" 

Add support for new "stat.big-num" boolean option.

This allows a user to set a default for "--no-big-num" for "perf stat"
commands.

--
$ perf config stat.big-num
$ perf stat --event cycles /bin/true

 Performance counter stats for '/bin/true':

   778,849  cycles
[...]
$ perf config stat.big-num=false
$ perf config stat.big-num
stat.big-num=false
$ perf stat --event cycles /bin/true

 Performance counter stats for '/bin/true':

769622  cycles
[...]
--

There is an interaction with "--field-separator" that must be
accommodated, such that specifying "--big-num --field-separator={x}"
still reports an invalid combination of options.

Documentation for perf-config and perf-stat updated.

Signed-off-by: Paul A. Clarke 
---
v2:
- Documentation updates for perf-config and perf-stat.
- Changed from using 0/1 to false/true in the examples and documentation.

Testing results with a matrix of:
- nothing in .perfconfig, stat.big-num=false, stat.big-num=true
- --field-separator not set, --field-separator=:
- no "--big-num", --big-num, --no-big-num

$ perf config stat.big-num
$ perf stat --event cycles /bin/true

 Performance counter stats for '/bin/true':

   778,849  cycles  


   0.000570037 seconds time elapsed

   0.000619000 seconds user
   0.0 seconds sys


$ perf stat --event cycles --big-num /bin/true

 Performance counter stats for '/bin/true':

   763,003  cycles  


   0.000546281 seconds time elapsed

   0.000597000 seconds user
   0.0 seconds sys


$ perf stat --event cycles --no-big-num /bin/true

 Performance counter stats for '/bin/true':

810753  cycles  


   0.000582670 seconds time elapsed

   0.000638000 seconds user
   0.0 seconds sys


$ perf stat --event cycles --field-separator=: /bin/true
759523::cycles:333196:100.00::
$ perf stat --event cycles --big-num --field-separator=: /bin/true
-B option not supported with -x

 Usage: perf stat [] []

-B, --big-num print large numbers with thousands' separators
-x, --field-separator 
  print counts with custom separator
$ perf stat --event cycles --no-big-num --field-separator=: /bin/true
782610::cycles:343606:100.00::
$ perf config stat.big-num=false
$ perf config stat.big-num
stat.big-num=false
$ perf stat --event cycles /bin/true

 Performance counter stats for '/bin/true':

769622  cycles  


   0.000545743 seconds time elapsed

   0.00060 seconds user
   0.0 seconds sys


$ perf stat --event cycles --big-num /bin/true

 Performance counter stats for '/bin/true':

   788,694  cycles  


   0.000565276 seconds time elapsed

   0.000622000 seconds user
   0.0 seconds sys


$ perf stat --event cycles --no-big-num /bin/true

 Performance counter stats for '/bin/true':

808283  cycles  


   0.000575508 seconds time elapsed

   0.000632000 seconds user
   0.0 seconds sys


$ perf stat --event cycles --field-separator=: /bin/true
809296::cycles:355486:100.00::
$ perf stat --event cycles --big-num --field-separator=: /bin/true
-B option not supported with -x

 Usage: perf stat [] []

-B, --big-num print large numbers with thousands' separators
-x, --field-separator 
  print counts with custom separator
$ perf stat --event cycles --no-big-num --field-separator=: /bin/true
795679::cycles:349824:100.00::
$ perf config stat.big-num=true
$ perf config stat.big-num
stat.big-num=true
$ perf stat --event cycles /bin/true

 Performance counter stats for '/bin/true':

   823,114  cycles  


   0.000577809 seconds time elapsed

   0.000643000 seconds user
   0.0 seconds sys


$ perf stat --event cycles --big-num /bin/true

 Performance counter stats for '/bin/true':

   778,824  cycles  


   0.000551584 seconds time elapsed

   0.000603000 seconds user
   0.0 seconds sys


$ perf stat --event cycles --no-big-num /bin/true

 Performance counter stats for '/bin/true':

789190  cycles  


   0.000574797 seconds time elapsed

   0.000637000 seconds user
   0.0 seconds sys


$ perf stat --event cycles --field-separator=: /bin/true
780405::cycles:343394:100.00::
$ perf stat --event cycles --big-num --field-separator=: /bin/true
-B option not supported with -x

 Usage: perf stat

Re: [RFC PATCH] tick/sched: update full_nohz status after SCHED dep is cleared

2020-05-20 Thread Frederic Weisbecker

Hi Juri,

On Wed, May 20, 2020 at 04:04:02PM +0200, Juri Lelli wrote:
> After tasks enter or leave a runqueue (wakeup/block) SCHED full_nohz
> dependency is checked (via sched_update_tick_dependency()). In case tick
> can be stopped on a CPU (see sched_can_stop_tick() for details), SCHED
> dependency for such CPU is cleared. However, this new information is not
> used right away to actually stop the tick.
> 
> In CONFIG_PREEMPT systems booted with threadirqs option, sched clock
> tick is serviced by an actual task (ksoftirqd corresponding to the CPU
> where tick timer fired).

I must confess I haven't tested threaded IRQs but I was
pretty sure that the timer tick is always serviced on hardirq.

Now the timer list callbacks are executed on softirqs. So if the
tick itself, executed on hardirq, sees pending timers, it raise
the softirq which wakes up ksoftirqd on forced irq thread mode
while calling irq_exit(). Then tick_nohz_irq_exit() sees ksoftirqd
and the current task on the runqueue, which together can indeed prevent
from turning off the tick. But then the root cause is pending timer
list callbacks.

> So, in case a CPU was running a single task,
> servicing the timer involves exiting full nozh mode. Problem at this
> point is that we might lose chances to enter back into full nozh mode,
> since info about ksoftirqd thread going back to sleep is not used (as
> mentioned above).

It should enter into nohz_full mode in the next tick, which is usually
a reasonable delay. If you need guarantee that the tick is stopped before
resuming userspace, you need a stronger machinery such as the task isolation
patchset.

Let's have a look at the trace below:

> ksoftirqd/19-125   [019]   170.700754: softirq_entry:vec=1 
> [action=TIMER]
> ksoftirqd/19-125   [019]   170.700755: softirq_exit: vec=1 
> [action=TIMER]
> ksoftirqd/19-125   [019]   170.700756: softirq_entry:vec=7 
> [action=SCHED]
> ksoftirqd/19-125   [019]   170.700757: softirq_exit: vec=7 
> [action=SCHED]
> ksoftirqd/19-125   [019]   170.700759: sched_switch: ksoftirqd/19:125 
> [120] S ==> sysjitter:2459 [120]
>sysjitter-2459  [019]   170.701740: local_timer_entry:vector=236
>sysjitter-2459  [019]   170.701742: softirq_raise:vec=1 
> [action=TIMER]

See here the tick sees pending timer callbacks so it raises the timer softirq.

>sysjitter-2459  [019]   170.701743: softirq_raise:vec=7 
> [action=SCHED]

Oh and the scheduler tick activates the scheduler softirq as well.

>sysjitter-2459  [019]   170.701744: local_timer_exit: vector=236
>sysjitter-2459  [019]   170.701747: sched_wakeup: ksoftirqd/19:125 
> [120] success=1 CPU:019
>sysjitter-2459  [019]   170.701748: tick_stop:success=0 
> dependency=SCHED
>sysjitter-2459  [019]   170.701749: irq_work_entry:   vector=246
>sysjitter-2459  [019]   170.701750: irq_work_exit:vector=246
>sysjitter-2459  [019]   170.701751: tick_stop:success=0 
> dependency=SCHED
>sysjitter-2459  [019]   170.701753: sched_switch: sysjitter:2459 
> [120] R ==> ksoftirqd/19:125 [120]
> ksoftirqd/19-125   [019]   170.701754: softirq_entry:vec=1 
> [action=TIMER]
> ksoftirqd/19-125   [019]   170.701756: softirq_exit: vec=1 
> [action=TIMER]
> ksoftirqd/19-125   [019]   170.701756: softirq_entry:vec=7 
> [action=SCHED]
> ksoftirqd/19-125   [019]   170.701758: softirq_exit: vec=7 
> [action=SCHED]
> ksoftirqd/19-125   [019]   170.701759: sched_switch: ksoftirqd/19:125 
> [120] S ==> sysjitter:2459 [120]
>sysjitter-2459  [019]   170.702740: local_timer_entry:vector=236
>sysjitter-2459  [019]   170.702742: softirq_raise:vec=1 
> [action=TIMER]

A new tick but we still have pending timer callback so we'll need to wakeup 
ksoftirqd
again.

I think you should trace timers and check which one is concerned here.

Thanks.

Re: [PATCH 1/2] kvm: cosmetic: remove wrong braces in kvm_init_msr_list switch

Maxim Levitsky  writes:

> I think these were added accidentally.
>
> Signed-off-by: Maxim Levitsky 
> ---
>  arch/x86/kvm/x86.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 471fccf7f8501..fe3a24fd6b263 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5299,7 +5299,7 @@ static void kvm_init_msr_list(void)
>
> !intel_pt_validate_hw_cap(PT_CAP_single_range_output)))
>   continue;
>   break;
> - case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: {
> + case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B:
>   if (!kvm_cpu_cap_has(X86_FEATURE_INTEL_PT) ||
>   msrs_to_save_all[i] - MSR_IA32_RTIT_ADDR0_A >=
>   
> intel_pt_validate_hw_cap(PT_CAP_num_address_ranges) * 2)
> @@ -5314,7 +5314,6 @@ static void kvm_init_msr_list(void)
>   if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
>   min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))
>   continue;
> - }
>   default:
>   break;
>   }

Reviewed-by: Vitaly Kuznetsov 

-- 
Vitaly

Re: [TEGRA194_CPUFREQ Patch 1/3] firmware: tegra: adding function to get BPMP data

2020-05-20 Thread Rob Herring

On Wed, May 20, 2020 at 9:39 AM Thierry Reding  wrote:
>
> On Wed, May 20, 2020 at 08:43:03AM -0600, Rob Herring wrote:
> > On Tue, Apr 7, 2020 at 4:05 AM Thierry Reding  
> > wrote:
> > >
> > > On Wed, Dec 04, 2019 at 03:21:38PM +0530, Viresh Kumar wrote:
> > > > On 04-12-19, 10:33, Thierry Reding wrote:
> > > > > Yeah, the code that registers this device is in drivers/base/cpu.c in
> > > > > register_cpu(). It even retrieves the device tree node for the CPU 
> > > > > from
> > > > > device tree and stores it in cpu->dev.of_node, so we should be able to
> > > > > just pass >dev to tegra_bpmp_get() in order to retrieve a 
> > > > > reference
> > > > > to the BPMP.
> > > > >
> > > > > That said, I'm wondering if perhaps we could just add a compatible
> > > > > string to the /cpus node for cases like this where we don't have an
> > > > > actual device representing the CPU complex. There are a number of CPU
> > > > > frequency drivers that register dummy devices just so that they have
> > > > > something to bind a driver to.
> > > > >
> > > > > If we allow the /cpus node to represent the CPU complex (if no other
> > > > > "device" does that yet), we can add a compatible string and have the
> > > > > cpufreq driver match on that.
> > > > >
> > > > > Of course this would be slightly difficult to retrofit into existing
> > > > > drivers because they'd need to remain backwards compatible with 
> > > > > existing
> > > > > device trees. But it would allow future drivers to do this a little 
> > > > > more
> > > > > elegantly. For some SoCs this may not matter, but especially once you
> > > > > start depending on additional resources this would come in handy.
> > > > >
> > > > > Adding Rob and the device tree mailing list for feedback on this idea.
> > > >
> > > > Took some time to find this thread, but something around this was
> > > > suggested by Rafael earlier.
> > > >
> > > > https://lore.kernel.org/lkml/8139001.q4ev8yg...@vostro.rjw.lan/
> > >
> > > I gave this a try and came up with the following:
> > >
> > > --- >8 ---
> > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
> > > b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > index f4ede86e32b4..e4462f95f0b3 100644
> > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > @@ -1764,6 +1764,9 @@ bpmp_thermal: thermal {
> > > };
> > >
> > > cpus {
> > > +   compatible = "nvidia,tegra194-ccplex";
> > > +   nvidia,bpmp = <>;
> >
> > Is there more than 1 bpmp? If not you don't need this. Just lookup the
> > node by compatible.
>
> There no SoCs currently than need to differentiate between multiple
> BPMPs, so yes, it would be possible to look up the node by compatible.
> But we also used to assume that PCs would only ever come with a single
> GPU or audio card and that's always caused a lot of work to clean up
> when it turned out to no longer be true.

Job security. ;)

> Also, we already have a couple of devices referencing the BPMP by
> phandle like this, so having this in a CCPLEX node would keep things
> consistent.
>
> One of the reasons why we initially did it this way was also so that we
> could make the dependencies explicit within device tree. If we look up
> by compatible string, then the driver is the only one with the knowledge
> about where to get at it. If we have the explicit reference we at least
> have a chance of determining the dependency by just looking at the
> device tree.

This case probably makes sense, but then driver dependencies can
evolve and you'd be updating the DT for every dependency. There's just
this general mindset that a driver can't look at the DT outside of its
own node.

> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > --- >8 ---
> > >
> > > Now I can do something rougly like this, although I have a more complete
> > > patch locally that also gets rid of all the global variables because we
> > > now actually have a struct platform_device that we can anchor everything
> > > at:
> > >
> > > --- >8 ---
> > > static const struct of_device_id tegra194_cpufreq_of_match[] = {
> > > { .compatible = "nvidia,tegra194-ccplex", },
> > > { /* sentinel */ }
> > > };
> > > MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
> > >
> > > static struct platform_driver tegra194_ccplex_driver = {
> > > .driver = {
> > > .name = "tegra194-cpufreq",
> > > .of_match_table = tegra194_cpufreq_of_match,
> > > },
> > > .probe = tegra194_cpufreq_probe,
> > > .remove = tegra194_cpufreq_remove,
> > > };
> > > module_platform_driver(tegra194_ccplex_driver);
> > > --- >8 ---
> > >
> > > I don't think that's exactly what Rafael (Cc'ed) had in mind, since the
> > > above thread seems to have mostly talked about binding a driver to each
> > > individual CPU.
> > >
> > > But this seems a lot better than having to instantiate a device

Re: [PATCH] ARM: pass -msoft-float to gcc earlier

2020-05-20 Thread Nick Desaulniers

On Wed, May 20, 2020 at 1:36 AM Szabolcs Nagy  wrote:
>
> The 05/19/2020 17:38, Nick Desaulniers wrote:
> > sorry, hit tab/enter too soon...
> >
> > On Tue, May 19, 2020 at 5:37 PM Nick Desaulniers
> >  wrote:
> > >
> > > On Tue, May 19, 2020 at 3:09 PM Arnd Bergmann  wrote:
> > > >
> > > > Szabolcs Nagy ran into a kernel build failure with a custom gcc
> > > > toochain that sets -mfpu=auto -mfloat-abi=hard:
> > > >
> > > >  /tmp/ccmNdcdf.s:1898: Error: selected processor does not support 
> > > > `cpsid i' in ARM mode
> > > >
> > > > The problem is that $(call cc-option, -march=armv7-a) fails before the
> > > > kernel overrides the gcc options to also pass -msoft-float.
> > >
> > > The call to `$(call cc-option, -march=armv7-a) is th
> >
> > The call to `$(call cc-option, -march=armv7-a) is the one that fails or...?
>
> the flag -march=armv7-a is invalid if the float abi
> is hard and no fpu is specified (since gcc-8).
>
> either an fpu should be specified or -march=armv7-a+fp
> (my toolchain was configured with the latter and it does
> not work if the kernel overrides it with -march=armv7-a)
>
> because of this cc-option failure the kernel goes on to
> pass nonsense flags everywhere (-march=armv5t) and some
> compilation eventually fails with an asm error.

Cool, thanks for the additional info.  Arnd, if you wanted to include
more of that snippet the commit message when submitting, I wouldn't
complain. :)
Reviewed-by: Nick Desaulniers 

>
> > > >
> > > > Move the option to the beginning the Makefile, before we call
> > >
> > > beginning of the
> > >
> > > > cc-option for the first time.
> > > >
> > > > Reported-by: Szabolcs Nagy 
> > > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87302
> > > > Signed-off-by: Arnd Bergmann 
> > >
> > > Moving this looks harmless enough, though it's not clear to me how the
> > > failure you're describing would occur.  I don't see calls to as-instr
> > > in arch/arm/Makefile.  Which object is being built before -msoft-float
> > > is being set?
> >
> > ... ^
> >
> > >
> > > > ---
> > > >  arch/arm/Makefile | 4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > index 7d5cd0f85461..e428ea6eb0fa 100644
> > > > --- a/arch/arm/Makefile
> > > > +++ b/arch/arm/Makefile
> > > > @@ -16,6 +16,8 @@ LDFLAGS_vmlinux   += --be8
> > > >  KBUILD_LDFLAGS_MODULE  += --be8
> > > >  endif
> > > >
> > > > +KBUILD_CFLAGS  += -msoft-float
> > > > +
> > > >  ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
> > > >  KBUILD_LDS_MODULE  += $(srctree)/arch/arm/kernel/module.lds
> > > >  endif
> > > > @@ -135,7 +137,7 @@ AFLAGS_ISA  :=$(CFLAGS_ISA)
> > > >  endif
> > > >
> > > >  # Need -Uarm for gcc < 3.x
> > > > -KBUILD_CFLAGS  +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) 
> > > > $(call cc-option,-mshort-load-bytes,$(call 
> > > > cc-option,-malignment-traps,)) -msoft-float -Uarm
> > > > +KBUILD_CFLAGS  +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) 
> > > > $(call cc-option,-mshort-load-bytes,$(call 
> > > > cc-option,-malignment-traps,)) -Uarm
> > > >  KBUILD_AFLAGS  +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) 
> > > > -include asm/unified.h -msoft-float
> > > >
> > > >  CHECKFLAGS += -D__arm__
> > > > --
> > > > 2.26.2
> > > >
> >
> > --
> > Thanks,
> > ~Nick Desaulniers
>
> --



-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 20/20] maccess: return -ERANGE when copy_from_kernel_nofault_allowed fails

2020-05-20 Thread Christoph Hellwig

On Wed, May 20, 2020 at 08:02:55PM +0900, Masami Hiramatsu wrote:
> Can you also update the kerneldoc comment too?

Sure, done.

Re: [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips

2020-05-20 Thread Bjorn Helgaas

On Tue, May 19, 2020 at 04:33:58PM -0400, Jim Quinlan wrote:
> This patchset expands the usefulness of the Broadcom Settop Box PCIe
> controller by building upon the PCIe driver used currently by the
> Raspbery Pi.  Other forms of this patchset were submitted by me years
> ago and not accepted; the major sticking point was the code required
> for the DMA remapping needed for the PCIe driver to work [1].
> 
> There have been many changes to the DMA and OF subsystems since that
> time, making a cleaner and less intrusive patchset possible.  This
> patchset implements a generalization of "dev->dma_pfn_offset", except
> that instead of a single scalar offset it provides for multiple
> offsets via a function which depends upon the "dma-ranges" property of
> the PCIe host controller.  This is required for proper functionality
> of the BrcmSTB PCIe controller and possibly some other devices.
> 
> [1] 
> https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101...@gmail.com/
> 
> Jim Quinlan (15):
>   PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
>   ahci_brcm: fix use of BCM7216 reset controller
>   dt-bindings: PCI: Add bindings for more Brcmstb chips
>   PCI: brcmstb: Add compatibily of other chips
>   PCI: brcmstb: Add suspend and resume pm_ops
>   PCI: brcmstb: Asserting PERST is different for 7278
>   PCI: brcmstb: Add control of rescal reset
>   of: Include a dev param in of_dma_get_range()
>   device core: Add ability to handle multiple dma offsets
>   dma-direct: Invoke dma offset func if needed
>   arm: dma-mapping: Invoke dma offset func if needed
>   PCI: brcmstb: Set internal memory viewport sizes
>   PCI: brcmstb: Accommodate MSI for older chips
>   PCI: brcmstb: Set bus max burst side by chip type
>   PCI: brcmstb: add compatilbe chips to match list

If you have occasion to post a v2 for other reasons,

s/PCIE_BRCMSTB depends on ARCH_BRCMSTB/Allow PCIE_BRCMSTB on ARCH_BRCMSTB also/
s/ahci_brcm: fix use of BCM7216 reset controller/ata: ahci_brcm: Fix .../
s/Add compatibily of other chips/Add bcm7278 register info/
s/Asserting PERST is different for 7278/Add bcm7278 PERST support/
s/Set bus max burst side/Set bus max burst size/
s/add compatilbe chips.*/Add bcm7211, bcm7216, bcm7445, bcm7278 to match list/

Rewrap commit logs to use full 75 character lines (to allow for the 4
spaces added by git log).

In commit logs, s/This commit// (use imperative mood instead).

In "Accommodate MSI for older chips" commit log, s/commont/common/.

>  .../bindings/pci/brcm,stb-pcie.yaml   |  40 +-
>  arch/arm/include/asm/dma-mapping.h|  17 +-
>  drivers/ata/ahci_brcm.c   |  14 +-
>  drivers/of/address.c  |  54 ++-
>  drivers/of/device.c   |   2 +-
>  drivers/of/of_private.h   |   8 +-
>  drivers/pci/controller/Kconfig|   4 +-
>  drivers/pci/controller/pcie-brcmstb.c | 403 +++---
>  include/linux/device.h|   9 +-
>  include/linux/dma-direct.h|  16 +
>  include/linux/dma-mapping.h   |  44 ++
>  kernel/dma/Kconfig|  12 +
>  12 files changed, 542 insertions(+), 81 deletions(-)
> 
> -- 
> 2.17.1
>

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

2020-05-20 Thread Jeffrey Hugo

On 5/20/2020 9:59 AM, Greg Kroah-Hartman wrote:

On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:

On 5/20/2020 2:34 AM, Daniel Vetter wrote:

On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
wrote:

On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:

On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:

On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:

On 5/18/2020 11:08 PM, Dave Airlie wrote:

On Fri, 15 May 2020 at 00:12, Jeffrey Hugo wrote:

Introduction:
Qualcomm Cloud AI 100 is a PCIe adapter card which contains a dedicated
SoC ASIC for the purpose of efficently running Deep Learning inference
workloads in a data center environment.

The offical press release can be found at -
https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-efficient-artificial-intelligence-inference

The offical product website is -
https://www.qualcomm.com/products/datacenter-artificial-intelligence

At the time of the offical press release, numerious technology news sites
also covered the product. Doing a search of your favorite site is likely
to find their coverage of it.

It is our goal to have the kernel driver for the product fully upstream.
The purpose of this RFC is to start that process. We are still doing
development (see below), and thus not quite looking to gain acceptance quite
yet, but now that we have a working driver we beleive we are at the stage
where meaningful conversation with the community can occur.

Hi Jeffery,

Just wondering what the userspace/testing plans for this driver.

This introduces a new user facing API for a device without pointers to
users or tests for that API.

We have daily internal testing, although I don't expect you to take my word
for that.

I would like to get one of these devices into the hands of Linaro, so that
it can be put into KernelCI. Similar to other Qualcomm products. I'm trying
to convince the powers that be to make this happen.

Regarding what the community could do on its own, everything but the Linux
driver is considered proprietary - that includes the on device firmware and
the entire userspace stack. This is a decision above my pay grade.

Ok, that's a decision you are going to have to push upward on, as we
really can't take this without a working, open, userspace.

Uh wut.

So the merge criteria for drivers/accel (atm still drivers/misc but I
thought that was interim until more drivers showed up) isn't actually
"totally-not-a-gpu accel driver without open source userspace".

Instead it's "totally-not-a-gpu accel driver without open source
userspace" _and_ you have to be best buddies with Greg. Or at least
not be on the naughty company list. Since for habanalabs all you
wanted is a few test cases to exercise the ioctls. Not the entire
userspace.

Also, to be fair, I have changed my mind after seeing the mess of
complexity that these "ioctls for everyone!" type of pass-through
these kinds of drivers are creating. You were right, we need open
userspace code in order to be able to properly evaluate and figure out
what they are doing is right or not and be able to maintain things over
time correctly.

So I was wrong, and you were right, my apologies for my previous
stubbornness.

Awesome and don't worry, I'm pretty sure we've all been stubborn
occasionally :-)

From a drivers/gpu pov I think still not quite there since we also
want to see the compiler for these programmable accelerator thingies.
But just having a fairly good consensus that "userspace library with
all the runtime stuff excluding compiler must be open" is a huge step
forward. Next step may be that we (kernel overall, drivers/gpu will
still ask for the full thing) have ISA docs for these programmable
things, so that we can also evaluate that aspect and gauge how many
security issues there might be. Plus have a fighting chance to fix up
the security leaks when (post smeltdown I don't really want to
consider this an if) someone finds a hole in the hw security wall. At
least in drivers/gpu we historically have a ton of drivers with
command checkers to validate what userspace wants to run on the
accelerator thingie. Both in cases where the hw was accidentally too
strict, and not strict enough.

I think this provides a pretty clear guidance on what you/the community are
looking for, both now and possibly in the future.

Thank you.

From my perspective, it would be really nice if there was something like
Mesa that was a/the standard for these sorts of accelerators. Its somewhat
the wild west, and we've struggled with it.

Put a first cut at such a thing out there and see how it goes! Nothing
is preventing you from starting such a project, and it would be most
welcome as you have seen.

I wish. I'll float the idea, but don't hold your breath.

--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH] xen: move xen_setup_callback_vector() definition to include/xen/hvm.h

Kbuild test robot reports the following problem on ARM:

>> drivers/xen/events/events_base.c:1664:6: warning: no previous prototype
  for 'xen_setup_callback_vector' [-Wmissing-prototypes]
1664 | void xen_setup_callback_vector(void) {}
|  ^
The problem is that xen_setup_callback_vector is a x86 only thing, its
definition is present in arch/x86/xen/xen-ops.h but not on ARM. In
events_base.c we have a stub for !CONFIG_XEN_PVHVM but it is not
declared as 'static'.

On x86 the situation is hardly better: drivers/xen/events/events_base.c
doesn't include 'xen-ops.h' from arch/x86/xen/, it includes its namesake
from include/xen/ so we also get the 'no previous prototype' warning.

Currently, xen_setup_callback_vector() has two call sites: one in
drivers/xen/events_base.c and another in arch/x86/xen/suspend_hvm.c. The
former is placed under #ifdef CONFIG_X86 and the later is only compiled
in when CONFIG_XEN_PVHVM.

Resolve the issue by moving xen_setup_callback_vector() declaration to
arch neutral 'include/xen/hvm.h' as the implementation lives in arch
neutral drivers/xen/events/events_base.c.

Reported-by: kbuild test robot 
Signed-off-by: Vitaly Kuznetsov 
---
- The patch needs to be applied on top of 'x86/xen: Split HVM vector callback
 setup and interrupt gate allocation' ('tip/entry' branch currently). This
 patch doesn't introduce the issue (and that's why I don't add 'Fixes:' tag)
 but it renames xen_callback_vector() -> xen_setup_callback_vector().
---
 arch/x86/xen/suspend_hvm.c | 1 +
 arch/x86/xen/xen-ops.h | 1 -
 include/xen/hvm.h  | 2 ++
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/suspend_hvm.c b/arch/x86/xen/suspend_hvm.c
index 5152afe16876..9d548b0c772f 100644
--- a/arch/x86/xen/suspend_hvm.c
+++ b/arch/x86/xen/suspend_hvm.c
@@ -2,6 +2,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 1cc1568bfe04..937a53e73ea5 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -55,7 +55,6 @@ void xen_enable_sysenter(void);
 void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
 
-void xen_setup_callback_vector(void);
 void xen_hvm_init_shared_info(void);
 void xen_unplug_emulated_devices(void);
 
diff --git a/include/xen/hvm.h b/include/xen/hvm.h
index 0b15f8cb17fc..b7fd7fc9ad41 100644
--- a/include/xen/hvm.h
+++ b/include/xen/hvm.h
@@ -58,4 +58,6 @@ static inline int hvm_get_parameter(int idx, uint64_t *value)
 #define HVM_CALLBACK_VECTOR(x) (((uint64_t)HVM_CALLBACK_VIA_TYPE_VECTOR)<<\
HVM_CALLBACK_VIA_TYPE_SHIFT | (x))
 
+void xen_setup_callback_vector(void);
+
 #endif /* XEN_HVM_H__ */
-- 
2.25.4

Re: [next] i2c: mediatek: Use div_u64 for 64-bit division to fix 32-bit kernels

2020-05-20 Thread Randy Dunlap

On 5/20/20 3:31 AM, qii.w...@mediatek.com wrote:
> From: Qii Wang 
> 
> Use div_u64 for 64-bit division, and change sample_ns type to
> unsigned int. Otherwise, the module will reference __udivdi3
> under 32-bit kernels, which is not allowed in kernel space.
> 
> Signed-off-by: Qii Wang 

Acked-by: Randy Dunlap  # build-tested

thanks.

> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 7020618..deef69e 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -551,7 +551,8 @@ static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
>   const struct i2c_spec_values *spec;
>   unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
>   unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
> - long long sample_ns = (10 * (sample_cnt + 1)) / clk_src;
> + unsigned int sample_ns = div_u64(10ULL * (sample_cnt + 1),
> +  clk_src);
>  
>   if (!i2c->dev_comp->timing_adjust)
>   return 0;
> 


-- 
~Randy

[tip:x86/entry 4/80] drivers/xen/events/events_base.c:1664:6: warning: no previous prototype for function 'xen_setup_callback_vector'

2020-05-20 Thread kbuild test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry
head:   095b7a3e7745e6fb7cf0a1c09967c4f43e76f8f4
commit: fad1940a6a856f59b073e8650e02052ce531154c [4/80] x86/xen: Split HVM 
vector callback setup and interrupt gate allocation
config: arm64-randconfig-r026-20200519 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
135b877874fae96b4372c8a3fbfaa8ff44ff86e3)
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
git checkout fad1940a6a856f59b073e8650e02052ce531154c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

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

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> drivers/xen/events/events_base.c:1664:6: warning: no previous prototype for 
>> function 'xen_setup_callback_vector' [-Wmissing-prototypes]
void xen_setup_callback_vector(void) {}
^
drivers/xen/events/events_base.c:1664:1: note: declare 'static' if the function 
is not intended to be used outside of this translation unit
void xen_setup_callback_vector(void) {}
^
static
drivers/xen/events/events_base.c:1665:20: warning: unused function 
'xen_alloc_callback_vector' [-Wunused-function]
static inline void xen_alloc_callback_vector(void) {}
^
2 warnings generated.

vim +/xen_setup_callback_vector +1664 drivers/xen/events/events_base.c

  1654  
  1655  static __init void xen_alloc_callback_vector(void)
  1656  {
  1657  if (!xen_have_vector_callback)
  1658  return;
  1659  
  1660  pr_info("Xen HVM callback vector for event delivery is 
enabled\n");
  1661  alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, 
xen_hvm_callback_vector);
  1662  }
  1663  #else
> 1664  void xen_setup_callback_vector(void) {}
  1665  static inline void xen_alloc_callback_vector(void) {}
  1666  #endif
  1667  

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


.config.gz
Description: application/gzip

Re: [PATCH v1] sdhci: tegra: Remove warnings about missing device-tree properties

2020-05-20 Thread Sowjanya Komatineni

On 5/20/20 4:26 AM, Ulf Hansson wrote:

On Wed, 20 May 2020 at 04:00, Dmitry Osipenko wrote:

19.05.2020 23:44, Sowjanya Komatineni пишет:

On 5/19/20 12:07 PM, Sowjanya Komatineni wrote:

On 5/19/20 11:41 AM, Sowjanya Komatineni wrote:

On 5/19/20 11:34 AM, Sowjanya Komatineni wrote:

On 5/19/20 9:33 AM, Dmitry Osipenko wrote:

19.05.2020 19:24, Thierry Reding пишет:

On Tue, May 19, 2020 at 05:05:27PM +0300, Dmitry Osipenko wrote:

19.05.2020 10:28, Ulf Hansson пишет:

On Sat, 16 May 2020 at 17:44, Dmitry Osipenko
wrote:

Several people asked me about the MMC warnings in the KMSG log and
I had to tell to ignore them because these warning are
irrelevant to
pre-Tegra210 SoCs.

Why are the warnings irrelevant?

That's what the DT binding doc says [1].

[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/mmc/nvidia%2Ctegra20-sdhci.txt

Although, looking at the driver's code and TRM docs, it seems
that all
those properties are really irrelevant only to the older Terga20
SoC. So
the binding doc is a bit misleading.

Nevertheless, the binding explicitly says that the properties are
optional, which is correct.

Optional only means that drivers must not fail if these properties
aren't found, it doesn't mean that the driver can't warn that they
are missing.

Quite possibly the only reason why they were made optional is because
they weren't part of the bindings since the beginning. Anything added
to a binding after the first public release has to be optional by
definition, otherwise DT ABI wouldn't be stable.

I think these warnings were added on purpose, though I also see that
there are only values for these in device tree for Tegra186 and
Tegra194
but not Tegra210 where these should also be necessary.

dt binding doc we have is common for MMC, SD and SDIO of all Tegras.
Its not mandatory to have both 3v3 and 1v8 in device tree as based
on signal mode.

As these driver strengths are SoC specific, they are part of Tegra
SoC specific device tree where same values will be applicable to all
Tegra SoC specific platforms.

Based on interface usage on platform, we use one or both of them
like sdcard supports dual voltage and we use both 3V3 and 1V8 but if
same interface is used for WIFI SD we use 1V8 only.

So made these dt properties as optional.

Other reason they are optional is, Tegra210 and prior has drive
strength settings part of apb_misc and Tegra186 and later has driver
strengths part of SDMMC controller. So,

- Pinctrls "sdmmc-3v3-drv" and "sdmmc-1v8-drv" for driver strengths
are applicable for Tegra210 and prior.
- dt properties pad-autocal-pull-up/down-offset-1v8/3v3-timeout are
for T186 onwards for driver strengths

Looks like dt binding doc need fix to clearly document these based
on SoC or agree with Yaml we can conditionally specify pinctrl or dt
properties based on SoC dependent.

Adding Sowjanya who wrote this code. Perhaps she can clarify why the
warnings were added. If these values /should/ be there on a subset of
Tegra, then I think we should keep them, or add them again, but
perhaps
add a better way of identifying when they are necessary and when
it is
safe to work without them.

That said, looking at those checks I wonder if they are perhaps just
wrong. Or at the very least they seem redundant. It looks to me like
they can just be:

if (tegra_host->pinctrl_state_XYZ == NULL) {
...
}

That !IS_ERR(...) doesn't seem to do anything. But in that case, it's
also obvious why we're warning about them on platforms where these
properties don't exist in DT.

As drive strengths are through dt properties for T186 and later and
thru pinctrl for T210 and prior, driver first checks for dt autocal
timeout pull-up/down properties and if they are not found, it then
checks for presence of pinctrl_state_xyx_drv only when valid
pinctrl_state_xyz is present.

Driver expects either pinctrl or dt properties and shows warning
when neither of them are present as its mandatory to use fixed
driver strengths when auto calibration fails.

err = device_property_read_u32(host->mmc->parent,
"nvidia,pad-autocal-pull-down-offset-3v3-timeout",
>pull_down_3v3_timeout);
if (err) {
if (!IS_ERR(tegra_host->pinctrl_state_3v3) &&
(tegra_host->pinctrl_state_3v3_drv == NULL))
pr_warn("%s: Missing autocal timeout 3v3-pad drvs\n",
mmc_hostname(host->mmc));
autocal->pull_down_3v3_timeout = 0;
}

So I think we either need to add those values where appropriate so
that
the warning doesn't show, or we need to narrow down where they are
really needed and add a corresponding condition.

But again, perhaps Sowjanya can help clarify if these really are only
needed on Tegra210 and later or if these also apply to older chips.

Either way will be cleaner to convert the DT binding to YAML rather
than
clutter the driver, IMO.

Auto calibration is present from Tegra30 onward and looking into
change where

Re: [PATCH v2 7/8] exec: Generic execfd support

2020-05-20 Thread Eric W. Biederman

Rob Landley  writes:

> On 5/18/20 7:33 PM, Eric W. Biederman wrote:
>> 
>> Most of the support for passing the file descriptor of an executable
>> to an interpreter already lives in the generic code and in binfmt_elf.
>> Rework the fields in binfmt_elf that deal with executable file
>> descriptor passing to make executable file descriptor passing a first
>> class concept.
>
> I was reading this to try to figure out how to do execve(NULL, argv[], envp) 
> to
> re-exec self after a vfork() in a chroot with no /proc, and hit the most 
> trivial
> quibble ever:

We have /proc/self/exe today.  If I understand you correctly you would
like to do the equivalent of 'execve("/proc/self/exe", argv[], envp[])'
without having proc mounted.

The file descriptor is stored in mm->exe_file.

Probably the most straight forward implementation is to allow
execveat(AT_EXE_FILE, ...).

You can look at binfmt_misc for how to reopen an open file descriptor.

>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -1323,7 +1323,10 @@ int begin_new_exec(struct linux_binprm * bprm)
>>   */
>>  set_mm_exe_file(bprm->mm, bprm->file);
>>  
>> +/* If the binary is not readable than enforce mm->dumpable=0 */
>
> then

It took me a minute yes good catch.

Eric

Re: [PATCH] kdb: Cleanup math with KDB_CMD_HISTORY_COUNT

2020-05-20 Thread Daniel Thompson

On Thu, May 07, 2020 at 04:11:46PM -0700, Douglas Anderson wrote:
> From code inspection the math in handle_ctrl_cmd() looks super sketchy
> because it subjects -1 from cmdptr and then does a "%
> KDB_CMD_HISTORY_COUNT".  It turns out that this code works because
> "cmdptr" is unsigned and KDB_CMD_HISTORY_COUNT is a nice power of 2.
> Let's make this a little less sketchy.
> 
> This patch should be a no-op.
> 
> Signed-off-by: Douglas Anderson 

Applied, thanks!

Re: [PATCH] mm, memcg: reclaim more aggressively before high allocator throttling

2020-05-20 Thread Michal Hocko

On Wed 20-05-20 15:37:12, Chris Down wrote:
> In Facebook production, we've seen cases where cgroups have been put
> into allocator throttling even when they appear to have a lot of slack
> file caches which should be trivially reclaimable.
> 
> Looking more closely, the problem is that we only try a single cgroup
> reclaim walk for each return to usermode before calculating whether or
> not we should throttle. This single attempt doesn't produce enough
> pressure to shrink for cgroups with a rapidly growing amount of file
> caches prior to entering allocator throttling.
> 
> As an example, we see that threads in an affected cgroup are stuck in
> allocator throttling:
> 
> # for i in $(cat cgroup.threads); do
> > grep over_high "/proc/$i/stack"
> > done
> [<0>] mem_cgroup_handle_over_high+0x10b/0x150
> [<0>] mem_cgroup_handle_over_high+0x10b/0x150
> [<0>] mem_cgroup_handle_over_high+0x10b/0x150
> 
> ...however, there is no I/O pressure reported by PSI, despite a lot of
> slack file pages:
> 
> # cat memory.pressure
> some avg10=78.50 avg60=84.99 avg300=84.53 total=5702440903
> full avg10=78.50 avg60=84.99 avg300=84.53 total=5702116959
> # cat io.pressure
> some avg10=0.00 avg60=0.00 avg300=0.00 total=78051391
> full avg10=0.00 avg60=0.00 avg300=0.00 total=78049640
> # grep _file memory.stat
> inactive_file 1370939392
> active_file 661635072
> 
> This patch changes the behaviour to retry reclaim either until the
> current task goes below the 10ms grace period, or we are making no
> reclaim progress at all. In the latter case, we enter reclaim throttling
> as before.

Let me try to understand the actual problem. The high memory reclaim has
a target which is proportional to the amount of charged memory. For most
requests that would be SWAP_CLUSTER_MAX though (resp. N times that where
N is the number of memcgs in excess up the hierarchy). I can see to be
insufficient if the memcg is already in a large excess but if the
reclaim can make a forward progress this should just work fine because
each charging context should reclaim at least the contributed amount.

Do you have any insight on why this doesn't work in your situation?
Especially with such a large inactive file list I would be really
surprised if the reclaim was not able to make a forward progress.

Now to your patch. I do not like it much to be honest.
MEM_CGROUP_RECLAIM_RETRIES is quite arbitrary and I neither like it in
memory_high_write because the that is an interruptible context so there
shouldn't be a good reason to give up after $FOO number of failed
attempts. try_charge and memory_max_write are slightly different because
we are invoking OOM killer based on the number of failed attempts.

Also if the current high reclaim scaling is insufficient then we should
be handling that via memcg_nr_pages_over_high rather than effectivelly
unbound number of reclaim retries.

That being said, the changelog should be more specific about the
underlying problem and if the real problem is in the reclaim target then
it should be handled by an increased but still fixed size. If the
throttling is just too aggressive and puts task into sleep even when a
reclaim has been performed then the throttling should be fixed.
-- 
Michal Hocko
SUSE Labs

[PATCH 0/2] Fix breakage from adding MSR_IA32_UMWAIT_CONTROL

2020-05-20 Thread Maxim Levitsky

Currently code in kvm_get_supported_msrs always
returns this msr as supported by KVM, however it
is not supported at all on AMD and it is only supported
on few select Intel systems.

This happened to work in native virtualization case,
because KVM's code also tries to read these msrs,
and on an exception drops them from the supported msr list.

However when running nested, and outer hypervisor set
to ignore unknown msrs, the read from this msr doesn't get
an excption, and thus KVM thinks that this msr should be on
supported msr list.

I don't think we should rely on exception to check if a feature
is supported since that msr can be even in theory assigned to something
else on AMD for example.

Also I included a cosmetic fix for an issue I found in the same function.

Best regards,
Maxim Levitsky

Maxim Levitsky (2):
  kvm: cosmetic: remove wrong braces in kvm_init_msr_list switch
  kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally

 arch/x86/kvm/x86.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

-- 
2.26.2

Re: clock_gettime64 vdso bug on 32-bit arm, rpi-4

2020-05-20 Thread Rich Felker

On Wed, May 20, 2020 at 04:41:29PM +0100, Szabolcs Nagy wrote:
> The 05/19/2020 22:31, Arnd Bergmann wrote:
> > On Tue, May 19, 2020 at 10:24 PM Adhemerval Zanella
> >  wrote:
> > > On 19/05/2020 16:54, Arnd Bergmann wrote:
> > > > Jack Schmidt reported a bug for the arm32 clock_gettimeofday64 vdso 
> > > > call last
> > > > month: https://github.com/richfelker/musl-cross-make/issues/96 and
> > > > https://github.com/raspberrypi/linux/issues/3579
> > > >
> > > > As Will Deacon pointed out, this was never reported on the mailing list,
> > > > so I'll try to summarize what we know, so this can hopefully be 
> > > > resolved soon.
> > > >
> > > > - This happened reproducibly on Linux-5.6 on a 32-bit Raspberry Pi 
> > > > patched
> > > >kernel running on a 64-bit Raspberry Pi 4b (bcm2711) when calling
> > > >clock_gettime64(CLOCK_REALTIME)
> > >
> > > Does it happen with other clocks as well?
> > 
> > Unclear.
> > 
> > > > - The kernel tree is at https://github.com/raspberrypi/linux/, but I 
> > > > could
> > > >   see no relevant changes compared to a mainline kernel.
> > >
> > > Is this bug reproducible with mainline kernel or mainline kernel can't be
> > > booted on bcm2711?
> > 
> > Mainline linux-5.6 should boot on that machine but might not have
> > all the other features, so I think users tend to use the raspberry pi
> > kernel sources for now.
> > 
> > > > - From the report, I see that the returned time value is larger than the
> > > >   expected time, by 3.4 to 14.5 million seconds in four samples, my
> > > >   guess is that a random number gets added in at some point.
> > >
> > > What kind code are you using to reproduce it? It is threaded or issue
> > > clock_gettime from signal handlers?
> > 
> > The reproducer is very simple without threads or signals,
> > see the start of https://github.com/richfelker/musl-cross-make/issues/96
> > 
> > It does rely on calling into the musl wrapper, not the direct vdso
> > call.
> > 
> > > > - From other sources, I found that the Raspberry Pi clocksource runs
> > > >   at 54 MHz, with a mask value of 0xff. From these numbers
> > > >   I would expect that reading a completely random hardware register
> > > >   value would result in an offset up to 1.33 billion seconds, which is
> > > >   around factor 100 more than the error we see, though similar.
> > > >
> > > > - The test case calls the musl clock_gettime() function, which falls 
> > > > back to
> > > >   the clock_gettime64() syscall on kernels prior to 5.5, or to the 
> > > > 32-bit
> > > >   clock_gettime() prior to Linux-5.1. As reported in the bug, 
> > > > Linux-4.19 does
> > > >   not show the bug.
> > > >
> > > > - The behavior was not reproduced on the same user space in qemu,
> > > >   though I cannot tell whether the exact same kernel binary was used.
> > > >
> > > > - glibc-2.31 calls the same clock_gettime64() vdso function on arm to
> > > >   implement clock_gettime(), but earlier versions did not. I have not
> > > >   seen any reports of this bug, which could be explained by users
> > > >   generally being on older versions.
> > > >
> > > > - As far as I can tell, there are no reports of this bug from other 
> > > > users,
> > > >   and so far nobody could reproduce it.
> 
> note: i could not reproduce it in qemu-system with these configs:
> 
> qemu-system-aarch64 + arm64 kernel + compat vdso
> qemu-system-aarch64 + kvm accel (on cortex-a72) + 32bit arm kernel
> qemu-system-arm + cpu max + 32bit arm kernel
> 
> so i think it's something specific to that user's setup
> (maybe rpi hw bug or gcc miscompiled the vdso or something
> with that particular linux, i built my own linux 5.6 because
> i did not know the exact kernel version where the bug was seen)
> 
> i don't have access to rpi (or other cortex-a53 where i
> can install my own kernel) so this is as far as i got.

If we have a binary of the kernel that's known to be failing on the
hardware, it would be useful to dump its vdso and examine the
disassembly to see if it was miscompiled.

Rich

[PATCH 1/2] kvm: cosmetic: remove wrong braces in kvm_init_msr_list switch

2020-05-20 Thread Maxim Levitsky

I think these were added accidentally.

Signed-off-by: Maxim Levitsky 
---
 arch/x86/kvm/x86.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 471fccf7f8501..fe3a24fd6b263 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5299,7 +5299,7 @@ static void kvm_init_msr_list(void)
 
!intel_pt_validate_hw_cap(PT_CAP_single_range_output)))
continue;
break;
-   case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: {
+   case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B:
if (!kvm_cpu_cap_has(X86_FEATURE_INTEL_PT) ||
msrs_to_save_all[i] - MSR_IA32_RTIT_ADDR0_A >=

intel_pt_validate_hw_cap(PT_CAP_num_address_ranges) * 2)
@@ -5314,7 +5314,6 @@ static void kvm_init_msr_list(void)
if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))
continue;
-   }
default:
break;
}
-- 
2.26.2

Re: [PATCH v2] printk/kdb: Redirect printk messages into kdb in any context

2020-05-20 Thread Daniel Thompson

On Wed, May 20, 2020 at 12:22:33PM +0200, Petr Mladek wrote:
> kdb has to get messages on consoles even when the system is stopped.
> It uses kdb_printf() internally and calls console drivers on its own.
> 
> It uses a hack to reuse an existing code. It sets "kdb_trap_printk"
> global variable to redirect even the normal printk() into the
> kdb_printf() variant.
> 
> The variable "kdb_trap_printk" is checked in printk_default() and
> it is ignored when printk is redirected to printk_safe in NMI context.
> Solve this by moving the check into printk_func().
> 
> It is obvious that it is not fully safe. But it does not make things
> worse. The console drivers are already called in this context by
> db_printf() direct calls.
> 
> Reported-by: Sumit Garg 
> Tested-by: Sumit Garg 
> Signed-off-by: Petr Mladek 

Reviewed-by: Daniel Thompson 


> ---
> Changes in v2:
> 
>+ more detailed commit message
> 
>  kernel/printk/printk.c  | 14 +-
>  kernel/printk/printk_safe.c |  7 +++
>  2 files changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 9a9b6156270b..63a1aa377cd9 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -35,7 +35,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -2036,18 +2035,7 @@ EXPORT_SYMBOL(vprintk);
>  
>  int vprintk_default(const char *fmt, va_list args)
>  {
> - int r;
> -
> -#ifdef CONFIG_KGDB_KDB
> - /* Allow to pass printk() to kdb but avoid a recursion. */
> - if (unlikely(kdb_trap_printk && kdb_printf_cpu < 0)) {
> - r = vkdb_printf(KDB_MSGSRC_PRINTK, fmt, args);
> - return r;
> - }
> -#endif
> - r = vprintk_emit(0, LOGLEVEL_DEFAULT, NULL, 0, fmt, args);
> -
> - return r;
> + return vprintk_emit(0, LOGLEVEL_DEFAULT, NULL, 0, fmt, args);
>  }
>  EXPORT_SYMBOL_GPL(vprintk_default);
>  
> diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
> index d9a659a686f3..7ccb821d0bfe 100644
> --- a/kernel/printk/printk_safe.c
> +++ b/kernel/printk/printk_safe.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -359,6 +360,12 @@ void __printk_safe_exit(void)
>  
>  __printf(1, 0) int vprintk_func(const char *fmt, va_list args)
>  {
> +#ifdef CONFIG_KGDB_KDB
> + /* Allow to pass printk() to kdb but avoid a recursion. */
> + if (unlikely(kdb_trap_printk && kdb_printf_cpu < 0))
> + return vkdb_printf(KDB_MSGSRC_PRINTK, fmt, args);
> +#endif
> +
>   /*
>* Try to use the main logbuf even in NMI. But avoid calling console
>* drivers that might have their own locks.
> -- 
> 2.26.1
>

[PATCH 2/2] kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally

2020-05-20 Thread Maxim Levitsky

This msr is only available when the host supports WAITPKG feature.

This breaks a nested guest, if the L1 hypervisor is set to ignore
unknown msrs, because the only other safety check that the
kernel does is that it attempts to read the msr and
rejects it if it gets an exception.

Fixes: 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by: Maxim Levitsky 
---
 arch/x86/kvm/x86.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fe3a24fd6b263..9c507b32b1b77 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))
continue;
+   break;
+   case MSR_IA32_UMWAIT_CONTROL:
+   if (!kvm_cpu_cap_has(X86_FEATURE_WAITPKG))
+   continue;
default:
break;
}
-- 
2.26.2

Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869

2020-05-20 Thread Florian Fainelli




On 5/20/2020 8:56 AM, Dan Murphy wrote:
> Andrew
> 
> On 5/20/20 10:36 AM, Andrew Lunn wrote:
 Hi Dan

 Having it required with PHY_INTERFACE_MODE_RGMII_ID or
 PHY_INTERFACE_MODE_RGMII_RXID is pretty unusual. Normally these
 properties are used to fine tune the delay, if the default of 2ns does
 not work.
>>> Also if the MAC phy-mode is configured with RGMII-ID and no internal
>>> delay
>>> values defined wouldn't that be counter intuitive?
>> Most PHYs don't allow the delay to be fine tuned. You just pass for
>> example PHY_INTERFACE_MODE_RGMII_ID to the PHY driver and it enables a
>> 2ns delay. That is what people expect, and is documented.
> 
>> Being able to tune the delay is an optional extra, which some PHYs
>> support, but that is always above and beyond
>> PHY_INTERFACE_MODE_RGMII_ID.
> 
> I am interested in knowing where that is documented.  I want to RTM I
> grepped for a few different words but came up empty
> 
> Since this is a tuneable phy we need to program the ID.  2ns is the
> default value
> 
> Maybe I can change it from Required to Configurable or Used.

I do not think this is properly documented, it is an established
practice, but it should be clearly documented somewhere, I do not know
whether that belongs in the PHY Device Tree binding or if this belongs
to the PHY documentation.
-- 
Florian

Re: Bad kfree of dma_parms in v5.7-rc5

2020-05-20 Thread Ulf Hansson

Marek, Tomi, Greg

On Wed, 20 May 2020 at 17:14, Ulf Hansson  wrote:
>
> On Wed, 20 May 2020 at 15:28, Marek Szyprowski  
> wrote:
> >
> > Hi Ulf,
> >
> > On 20.05.2020 15:12, Ulf Hansson wrote:
> > > + Greg
> > >
> > > On Wed, 20 May 2020 at 14:54, Marek Szyprowski  
> > > wrote:
> > >> On 20.05.2020 14:43, Tomi Valkeinen wrote:
> > >>> On 20/05/2020 12:22, Marek Szyprowski wrote:
> >  On 20.05.2020 11:18, Tomi Valkeinen wrote:
> > > On 20/05/2020 12:13, Marek Szyprowski wrote:
> > >> On 20.05.2020 11:00, Tomi Valkeinen wrote:
> > >>> Commit 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd ("driver core:
> > >>> platform: Initialize dma_parms for platform devices") v5.7-rc5 
> > >>> causes
> > >>> at least some v4l2 platform drivers to break when freeing resources.
> > >>>
> > >>> E.g. drivers/media/platform/ti-vpe/cal.c uses
> > >>> vb2_dma_contig_set_max_seg_size() and
> > >>> vb2_dma_contig_clear_max_seg_size() to manage the dma_params, and
> > >>> similar pattern is seen in other drivers too.
> > >>>
> > >>> After 9495b7e92f716ab2, vb2_dma_contig_set_max_seg_size() will not
> > >>> allocate anything, but vb2_dma_contig_clear_max_seg_size() will 
> > >>> still
> > >>> kfree the dma_params.
> > >>>
> > >>> I'm not sure what's the proper fix here. A flag somewhere to 
> > >>> indicate
> > >>> that vb2_dma_contig_set_max_seg_size() did allocate, and thus
> > >>> vb2_dma_contig_clear_max_seg_size() must free?
> > >>>
> > >>> Or drop the kzalloc and kfree totally, if dma_params is now supposed
> > >>> to always be there?
> > >> Thanks for reporting this issue!
> > >>
> > >> Once the mentioned commit has been merged, the code should assume 
> > >> that
> > >> the platform devices does have a struct dma_params allocated, so the
> > >> proper fix is to alloc dma_params only if the bus is not a platform
> > >> bus:
> > >>
> > >> if (!dev_is_platform(dev) && !dev->dma_parms) {
> > >> dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), 
> > >> GFP_KERNEL);
> > >>
> > >> same check for the free path.
> > > There is also "amba: Initialize dma_parms for amba devices". And the
> > > commit message says PCI devices do this too.
> > >
> > > Guessing this based on the device type doesn't sound like a good idea
> > > to me.
> >  Indeed. Then replace the allocation with a simple check for NULL
> >  dma_parms and return an error in such case. This should be enough for
> >  v5.8. Later we can simply get rid of those helpers and inline setting
> >  max segment size directly to the drivers.
> > > That seems like a good idea, in the long run.
> > >
> > >>> Is that valid either? Then we assume that dma_parms is always set up
> > >>> by someone else. That's true for platform devices and apparently some
> > >>> other devices, but is it true for all devices now?
> > >> # git grep vb2_dma_contig_set_max_seg_size | wc -l
> > >>
> > >> 18
> > >>
> > >> I've checked all clients of the vb2_dma_contig_set_max_seg_size
> > >> function. There are only 9 drivers, all of them are platform device
> > >> drivers. We don't care about off-tree users, so the proposed approach is
> > >> imho fine.
> > > Thanks for reporting and for looking into this. I apologize for the mess!
> > >
> > > There is one case, where the above solution could be a problem (unless
> > > I am wrong). That is, s5p_mfc_configure_2port_memory() that calls
> > > s5p_mfc_alloc_memdev(), which allocates/initializes an internal struct
> > > *device. Thus, this doesn't have the dev->dma_parms
> > > allocated/assigned.
> > Indeed, this one will fail.
> > > In other words, we would need to manage alloc/free for the
> > > dev->dma_parms to have a complete fix. Maybe in
> > > s5p_mfc_configure|unconfigure_2port_memory()!?
> > That would be the best place to allocate it.
> > > Additionally, I think reverting the offending commit, as discussed
> > > above, could cause even more issues, as it's even included for
> > > v5.6-stable kernels. I will go through all cases, more carefully this
> > > time, of how ->dma_parms is managed, to be sure there are no more
> > > conflicting cases.
> >
> > I've already posted a fix for ExynosDRM driver, which is also affected:
> > https://patchwork.kernel.org/patch/11559965/
>
> Alright, thanks for helping out!
>
> Please add a fixes/stable tag to it.
>
> Fixes: 9495b7e92f71 ("driver core: platform: Initialize dma_parms for
> platform devices")
> Cc: sta...@vger.kernel.org
>

FYI:

I have now double checked all cases where ->dma_params are being
allocated/freed. Besides those you (Marek/Tomi) you have found and
sent fixes for (many thanks!)  - I haven't found any additional cases
to worry about.

However, of course there are cleanups and removal of redundant code
that can be made, for some drivers/devices, which are based upon a
platform device. For example, some have

Re: [PATCH 00/13] Reconcile NUMA balancing decisions with the load balancer v6

2020-05-20 Thread Jirka Hladky

I have an update on netperf-cstate-small-cross-socket results.

Reported performance degradation of 2.5% for the UDP stream throughput
and 0.6% for the TCP throughput is for message size of 16kB. For
smaller message sizes, the performance drop is higher - up to 5% for
UDP throughput for a message size of 64B. See the numbers below [1]

We still think that it's acceptable given the gains in other
situations (this is again compared to 5.7 vanilla) :

* solved the performance drop upto 20%  with single instance
SPECjbb2005 benchmark on 8 NUMA node servers (particularly on AMD EPYC
Rome systems) => this performance drop was INCREASING with higher
threads counts (10% for 16 threads and 20 % for 32 threads)
* solved the performance drop upto 50% for low load scenarios
(SPECjvm2008 and NAS)

[1]
Hillf's patch compared to 5.7 (rc4) vanilla:

TCP throughput
Message size (B)
64  -2.6%
128-2.3%
256-2.6%
1024  -2.7%
2048  -2.2%
3312  -2.4%
4096  -1.1%
8192  -0.4%
16384-0.6%

UDP throughput
64  -5.0%
128-3.0%
256-3.0%
1024  -3.1%
2048  -3.3%
3312  -3.5%
4096  -4.0%
8192  -3.3%
16384-2.6%


On Wed, May 20, 2020 at 3:58 PM Jirka Hladky  wrote:
>
> Hi Hillf, Mel and all,
>
> thanks for the patch! It has produced really GOOD results.
>
> 1) It has fixed performance problems with 5.7 vanilla kernel for
> single-tenant workload and low system load scenarios, without
> performance degradation for the multi-tenant tasks. It's producing the
> same results as the previous proof-of-concept patch where
> adjust_numa_imbalance function was modified to be a no-op (returning
> the same value of imbalance as it gets on the input).
>
> 2) We have also added Mel's netperf-cstate-small-cross-socket test to
> our test battery:
> https://github.com/gormanm/mmtests/blob/master/configs/config-network-netperf-cstate-small-cross-socket
>
> Mel told me that he had seen significant performance improvements with
> 5.7 over 5.6 for the netperf-cstate-small-cross-socket scenario.
>
> Out of 6 different patches we have tested, your patch has performed
> the best for this scenario. Compared to vanilla, we see minimal
> performance degradation of 2.5% for the udp stream throughput and 0.6%
> for the tcp throughput. The testing was done on a dual-socket system
> with Gold 6132 CPU.
>
> @Mel - could you please test Hillf's patch with your full testing
> suite? So far, it looks very promising, but I would like to check the
> patch thoroughly to make sure it does not hurt performance in other
> areas.
>
> Thanks a lot!
> Jirka
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, May 19, 2020 at 6:32 AM Hillf Danton  wrote:
> >
> >
> > Hi Jirka
> >
> > On Mon, 18 May 2020 16:52:52 +0200 Jirka Hladky wrote:
> > >
> > > We have compared it against kernel with adjust_numa_imbalance disabled
> > > [1], and both kernels perform at the same level for the single-tenant
> > > jobs, but the proposed patch is bad for the multitenancy mode. The
> > > kernel with adjust_numa_imbalance disabled is a clear winner here.
> >
> > Double thanks to you for the tests!
> >
> > > We would be very interested in what others think about disabling
> > > adjust_numa_imbalance function. The patch is bellow. It would be great
> >
> > A minute...
> >
> > > to collect performance results for different scenarios to make sure
> > > the results are objective.
> >
> > I don't have another test case but a diff trying to confine the tool
> > in question back to the hard-coded 2's field.
> >
> > It's used in the first hunk below to detect imbalance before migrating
> > a task, and a small churn of code is added at another call site when
> > balancing idle CPUs.
> >
> > Thanks
> > Hillf
> >
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -1916,20 +1916,26 @@ static void task_numa_find_cpu(struct ta
> >  * imbalance that would be overruled by the load balancer.
> >  */
> > if (env->dst_stats.node_type == node_has_spare) {
> > -   unsigned int imbalance;
> > -   int src_running, dst_running;
> > +   unsigned int imbalance = 2;
> >
> > -   /*
> > -* Would movement cause an imbalance? Note that if src has
> > -* more running tasks that the imbalance is ignored as the
> > -* move improves the imbalance from the perspective of the
> > -* CPU load balancer.
> > -* */
> > -   src_running = env->src_stats.nr_running - 1;
> > -   dst_running = env->dst_stats.nr_running + 1;
> > -   imbalance = max(0, dst_running - src_running);
> > -   imbalance = adjust_numa_imbalance(imbalance, src_running);
> > +   //No imbalance computed without spare capacity
> > +   if (env->dst_stats.node_type != env->src_stats.node_type)
> > +   goto check_imb;
> > +
> > +

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

2020-05-20 Thread Greg Kroah-Hartman

On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:
> On 5/20/2020 2:34 AM, Daniel Vetter wrote:
> > On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
> >  wrote:
> > > 
> > > On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
> > > > > On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
> > > > > > On 5/18/2020 11:08 PM, Dave Airlie wrote:
> > > > > > > On Fri, 15 May 2020 at 00:12, Jeffrey Hugo  
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > Introduction:
> > > > > > > > Qualcomm Cloud AI 100 is a PCIe adapter card which contains a 
> > > > > > > > dedicated
> > > > > > > > SoC ASIC for the purpose of efficently running Deep Learning 
> > > > > > > > inference
> > > > > > > > workloads in a data center environment.
> > > > > > > > 
> > > > > > > > The offical press release can be found at -
> > > > > > > > https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-efficient-artificial-intelligence-inference
> > > > > > > > 
> > > > > > > > The offical product website is -
> > > > > > > > https://www.qualcomm.com/products/datacenter-artificial-intelligence
> > > > > > > > 
> > > > > > > > At the time of the offical press release, numerious technology 
> > > > > > > > news sites
> > > > > > > > also covered the product.  Doing a search of your favorite site 
> > > > > > > > is likely
> > > > > > > > to find their coverage of it.
> > > > > > > > 
> > > > > > > > It is our goal to have the kernel driver for the product fully 
> > > > > > > > upstream.
> > > > > > > > The purpose of this RFC is to start that process.  We are still 
> > > > > > > > doing
> > > > > > > > development (see below), and thus not quite looking to gain 
> > > > > > > > acceptance quite
> > > > > > > > yet, but now that we have a working driver we beleive we are at 
> > > > > > > > the stage
> > > > > > > > where meaningful conversation with the community can occur.
> > > > > > > 
> > > > > > > 
> > > > > > > Hi Jeffery,
> > > > > > > 
> > > > > > > Just wondering what the userspace/testing plans for this driver.
> > > > > > > 
> > > > > > > This introduces a new user facing API for a device without 
> > > > > > > pointers to
> > > > > > > users or tests for that API.
> > > > > > 
> > > > > > We have daily internal testing, although I don't expect you to take 
> > > > > > my word
> > > > > > for that.
> > > > > > 
> > > > > > I would like to get one of these devices into the hands of Linaro, 
> > > > > > so that
> > > > > > it can be put into KernelCI.  Similar to other Qualcomm products. 
> > > > > > I'm trying
> > > > > > to convince the powers that be to make this happen.
> > > > > > 
> > > > > > Regarding what the community could do on its own, everything but 
> > > > > > the Linux
> > > > > > driver is considered proprietary - that includes the on device 
> > > > > > firmware and
> > > > > > the entire userspace stack.  This is a decision above my pay grade.
> > > > > 
> > > > > Ok, that's a decision you are going to have to push upward on, as we
> > > > > really can't take this without a working, open, userspace.
> > > > 
> > > > Uh wut.
> > > > 
> > > > So the merge criteria for drivers/accel (atm still drivers/misc but I
> > > > thought that was interim until more drivers showed up) isn't actually
> > > > "totally-not-a-gpu accel driver without open source userspace".
> > > > 
> > > > Instead it's "totally-not-a-gpu accel driver without open source
> > > > userspace" _and_ you have to be best buddies with Greg. Or at least
> > > > not be on the naughty company list. Since for habanalabs all you
> > > > wanted is a few test cases to exercise the ioctls. Not the entire
> > > > userspace.
> > > 
> > > Also, to be fair, I have changed my mind after seeing the mess of
> > > complexity that these "ioctls for everyone!" type of pass-through
> > > these kinds of drivers are creating.  You were right, we need open
> > > userspace code in order to be able to properly evaluate and figure out
> > > what they are doing is right or not and be able to maintain things over
> > > time correctly.
> > > 
> > > So I was wrong, and you were right, my apologies for my previous
> > > stubbornness.
> > 
> > Awesome and don't worry, I'm pretty sure we've all been stubborn
> > occasionally :-)
> > 
> >  From a drivers/gpu pov I think still not quite there since we also
> > want to see the compiler for these programmable accelerator thingies.
> > But just having a fairly good consensus that "userspace library with
> > all the runtime stuff excluding compiler must be open" is a huge step
> > forward. Next step may be that we (kernel overall, drivers/gpu will
> > still ask for the full thing) have ISA docs for these programmable
> > things, so that we can also evaluate that aspect and gauge how many
> > security issues there might be. Plus have a fighting chance to fix up
> > the security leaks when (post smeltdown I don't

Re: clean up kernel_{read,write} & friends v2

2020-05-20 Thread Christoph Hellwig

ping?

On Wed, May 13, 2020 at 08:56:42AM +0200, Christoph Hellwig wrote:
> Hi Al,
> 
> this series fixes a few issues and cleans up the helpers that read from
> or write to kernel space buffers, and ensures that we don't change the
> address limit if we are using the ->read_iter and ->write_iter methods
> that don't need the changed address limit.
> 
> Changes since v1:
>  - __kernel_write must not take sb_writers
>  - unexported __kernel_write
---end quoted text---

Re: [PATCH V7 00/15] perf/x86: Add perf text poke events

2020-05-20 Thread Peter Zijlstra

On Tue, May 19, 2020 at 10:40:01PM -0300, Arnaldo Carvalho de Melo wrote:
> PeterZ, from what we discussed for the next merge Window, perhaps we
> should route the kernel bits via the tip tree while I will push the
> tooling bits on my 5.8 merge request to Linus, Ok?

Sure, I can take the kernel bits. Thanks!

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

2020-05-20 Thread Daniel Vetter

On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:
> On 5/20/2020 2:34 AM, Daniel Vetter wrote:
> > On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
> >  wrote:
> > > 
> > > On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
> > > > > On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
> > > > > > On 5/18/2020 11:08 PM, Dave Airlie wrote:
> > > > > > > On Fri, 15 May 2020 at 00:12, Jeffrey Hugo  
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > Introduction:
> > > > > > > > Qualcomm Cloud AI 100 is a PCIe adapter card which contains a 
> > > > > > > > dedicated
> > > > > > > > SoC ASIC for the purpose of efficently running Deep Learning 
> > > > > > > > inference
> > > > > > > > workloads in a data center environment.
> > > > > > > > 
> > > > > > > > The offical press release can be found at -
> > > > > > > > https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-efficient-artificial-intelligence-inference
> > > > > > > > 
> > > > > > > > The offical product website is -
> > > > > > > > https://www.qualcomm.com/products/datacenter-artificial-intelligence
> > > > > > > > 
> > > > > > > > At the time of the offical press release, numerious technology 
> > > > > > > > news sites
> > > > > > > > also covered the product.  Doing a search of your favorite site 
> > > > > > > > is likely
> > > > > > > > to find their coverage of it.
> > > > > > > > 
> > > > > > > > It is our goal to have the kernel driver for the product fully 
> > > > > > > > upstream.
> > > > > > > > The purpose of this RFC is to start that process.  We are still 
> > > > > > > > doing
> > > > > > > > development (see below), and thus not quite looking to gain 
> > > > > > > > acceptance quite
> > > > > > > > yet, but now that we have a working driver we beleive we are at 
> > > > > > > > the stage
> > > > > > > > where meaningful conversation with the community can occur.
> > > > > > > 
> > > > > > > 
> > > > > > > Hi Jeffery,
> > > > > > > 
> > > > > > > Just wondering what the userspace/testing plans for this driver.
> > > > > > > 
> > > > > > > This introduces a new user facing API for a device without 
> > > > > > > pointers to
> > > > > > > users or tests for that API.
> > > > > > 
> > > > > > We have daily internal testing, although I don't expect you to take 
> > > > > > my word
> > > > > > for that.
> > > > > > 
> > > > > > I would like to get one of these devices into the hands of Linaro, 
> > > > > > so that
> > > > > > it can be put into KernelCI.  Similar to other Qualcomm products. 
> > > > > > I'm trying
> > > > > > to convince the powers that be to make this happen.
> > > > > > 
> > > > > > Regarding what the community could do on its own, everything but 
> > > > > > the Linux
> > > > > > driver is considered proprietary - that includes the on device 
> > > > > > firmware and
> > > > > > the entire userspace stack.  This is a decision above my pay grade.
> > > > > 
> > > > > Ok, that's a decision you are going to have to push upward on, as we
> > > > > really can't take this without a working, open, userspace.
> > > > 
> > > > Uh wut.
> > > > 
> > > > So the merge criteria for drivers/accel (atm still drivers/misc but I
> > > > thought that was interim until more drivers showed up) isn't actually
> > > > "totally-not-a-gpu accel driver without open source userspace".
> > > > 
> > > > Instead it's "totally-not-a-gpu accel driver without open source
> > > > userspace" _and_ you have to be best buddies with Greg. Or at least
> > > > not be on the naughty company list. Since for habanalabs all you
> > > > wanted is a few test cases to exercise the ioctls. Not the entire
> > > > userspace.
> > > 
> > > Also, to be fair, I have changed my mind after seeing the mess of
> > > complexity that these "ioctls for everyone!" type of pass-through
> > > these kinds of drivers are creating.  You were right, we need open
> > > userspace code in order to be able to properly evaluate and figure out
> > > what they are doing is right or not and be able to maintain things over
> > > time correctly.
> > > 
> > > So I was wrong, and you were right, my apologies for my previous
> > > stubbornness.
> > 
> > Awesome and don't worry, I'm pretty sure we've all been stubborn
> > occasionally :-)
> > 
> >  From a drivers/gpu pov I think still not quite there since we also
> > want to see the compiler for these programmable accelerator thingies.
> > But just having a fairly good consensus that "userspace library with
> > all the runtime stuff excluding compiler must be open" is a huge step
> > forward. Next step may be that we (kernel overall, drivers/gpu will
> > still ask for the full thing) have ISA docs for these programmable
> > things, so that we can also evaluate that aspect and gauge how many
> > security issues there might be. Plus have a fighting chance to fix up
> > the security leaks when (post smeltdown I don't

Re: [PATCH 2/3] switchdev: mrp: Remove the variable mrp_ring_state

2020-05-20 Thread Ivan Vecera

On Wed, 20 May 2020 13:09:22 +
Horatiu Vultur  wrote:

> Remove the variable mrp_ring_state from switchdev_attr because is not
> used anywhere.
> The ring state is set using SWITCHDEV_OBJ_ID_RING_STATE_MRP.
> 
> Fixes: c284b5459008 ("switchdev: mrp: Extend switchdev API to offload MRP")
> Signed-off-by: Horatiu Vultur 
> ---
>  include/net/switchdev.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
> index ae7aeb0d1f9ca..db519957e134b 100644
> --- a/include/net/switchdev.h
> +++ b/include/net/switchdev.h
> @@ -62,7 +62,6 @@ struct switchdev_attr {
>  #if IS_ENABLED(CONFIG_BRIDGE_MRP)
>   u8 mrp_port_state;  /* MRP_PORT_STATE */
>   u8 mrp_port_role;   /* MRP_PORT_ROLE */
> - u8 mrp_ring_state;  /* MRP_RING_STATE */
>  #endif
>   } u;
>  };

Acked-by: Ivan Vecera

Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869

2020-05-20 Thread Dan Murphy


Andrew

On 5/20/20 10:36 AM, Andrew Lunn wrote:

Hi Dan

Having it required with PHY_INTERFACE_MODE_RGMII_ID or
PHY_INTERFACE_MODE_RGMII_RXID is pretty unusual. Normally these
properties are used to fine tune the delay, if the default of 2ns does
not work.

Also if the MAC phy-mode is configured with RGMII-ID and no internal delay
values defined wouldn't that be counter intuitive?

Most PHYs don't allow the delay to be fine tuned. You just pass for
example PHY_INTERFACE_MODE_RGMII_ID to the PHY driver and it enables a
2ns delay. That is what people expect, and is documented.



Being able to tune the delay is an optional extra, which some PHYs
support, but that is always above and beyond
PHY_INTERFACE_MODE_RGMII_ID.


I am interested in knowing where that is documented.  I want to RTM I 
grepped for a few different words but came up empty


Since this is a tuneable phy we need to program the ID.  2ns is the 
default value


Maybe I can change it from Required to Configurable or Used.

Dan



  Andrew

Re: [PATCH 3.16 43/99] efi: Use early_mem() instead of early_io()

2020-05-20 Thread Ben Hutchings

On Wed, 2020-05-20 at 15:14 +0100, Ben Hutchings wrote:
> 3.16.84-rc1 review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Daniel Kiper 
> 
> commit abc93f8eb6e46a480485f19256bdbda36ec78a84 upstream.

I've now seen that this depends on the preceding commit 4fa62481e231
"arch/ia64: Define early_memunmap()".  I've queued that up as well.

Ben.

> Use early_mem*() instead of early_io*() because all mapped EFI regions
> are memory (usually RAM but they could also be ROM, EPROM, EEPROM, flash,
> etc.) not I/O regions. Additionally, I/O family calls do not work correctly
> under Xen in our case. early_ioremap() skips the PFN to MFN conversion
> when building the PTE. Using it for memory will attempt to map the wrong
> machine frame. However, all artificial EFI structures created under Xen
> live in dom0 memory and should be mapped/unmapped using early_mem*() family
> calls which map domain memory.
> 
> Signed-off-by: Daniel Kiper 
> Cc: Leif Lindholm 
> Cc: Mark Salter 
> Signed-off-by: Matt Fleming 
> Signed-off-by: Ben Hutchings 
> ---
>  arch/x86/platform/efi/efi.c | 28 ++--
>  drivers/firmware/efi/efi.c  |  4 ++--
>  2 files changed, 16 insertions(+), 16 deletions(-)
> 
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -435,7 +435,7 @@ void __init efi_unmap_memmap(void)
>  {
>   clear_bit(EFI_MEMMAP, );
>   if (memmap.map) {
> - early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
> + early_memunmap(memmap.map, memmap.nr_map * memmap.desc_size);
>   memmap.map = NULL;
>   }
>  }
> @@ -475,12 +475,12 @@ static int __init efi_systab_init(void *
>   if (!data)
>   return -ENOMEM;
>   }
> - systab64 = early_ioremap((unsigned long)phys,
> + systab64 = early_memremap((unsigned long)phys,
>sizeof(*systab64));
>   if (systab64 == NULL) {
>   pr_err("Couldn't map the system table!\n");
>   if (data)
> - early_iounmap(data, sizeof(*data));
> + early_memunmap(data, sizeof(*data));
>   return -ENOMEM;
>   }
>  
> @@ -512,9 +512,9 @@ static int __init efi_systab_init(void *
>  systab64->tables;
>   tmp |= data ? data->tables : systab64->tables;
>  
> - early_iounmap(systab64, sizeof(*systab64));
> + early_memunmap(systab64, sizeof(*systab64));
>   if (data)
> - early_iounmap(data, sizeof(*data));
> + early_memunmap(data, sizeof(*data));
>  #ifdef CONFIG_X86_32
>   if (tmp >> 32) {
>   pr_err("EFI data located above 4GB, disabling EFI.\n");
> @@ -524,7 +524,7 @@ static int __init efi_systab_init(void *
>   } else {
>   efi_system_table_32_t *systab32;
>  
> - systab32 = early_ioremap((unsigned long)phys,
> + systab32 = early_memremap((unsigned long)phys,
>sizeof(*systab32));
>   if (systab32 == NULL) {
>   pr_err("Couldn't map the system table!\n");
> @@ -545,7 +545,7 @@ static int __init efi_systab_init(void *
>   efi_systab.nr_tables = systab32->nr_tables;
>   efi_systab.tables = systab32->tables;
>  
> - early_iounmap(systab32, sizeof(*systab32));
> + early_memunmap(systab32, sizeof(*systab32));
>   }
>  
>   efi.systab = _systab;
> @@ -571,7 +571,7 @@ static int __init efi_runtime_init32(voi
>  {
>   efi_runtime_services_32_t *runtime;
>  
> - runtime = early_ioremap((unsigned long)efi.systab->runtime,
> + runtime = early_memremap((unsigned long)efi.systab->runtime,
>   sizeof(efi_runtime_services_32_t));
>   if (!runtime) {
>   pr_err("Could not map the runtime service table!\n");
> @@ -586,7 +586,7 @@ static int __init efi_runtime_init32(voi
>   efi_phys.set_virtual_address_map =
>   (efi_set_virtual_address_map_t *)
>   (unsigned long)runtime->set_virtual_address_map;
> - early_iounmap(runtime, sizeof(efi_runtime_services_32_t));
> + early_memunmap(runtime, sizeof(efi_runtime_services_32_t));
>  
>   return 0;
>  }
> @@ -595,7 +595,7 @@ static int __init efi_runtime_init64(voi
>  {
>   efi_runtime_services_64_t *runtime;
>  
> - runtime = early_ioremap((unsigned long)efi.systab->runtime,
> + runtime = early_memremap((unsigned long)efi.systab->runtime,
>   sizeof(efi_runtime_services_64_t));
>   if (!runtime) {
>   pr_err("Could not map the runtime service table!\n");
> @@ -610,7 +610,7 @@ static int __init efi_runtime_init64(voi
>

Re: [PATCH 3.16 37/99] clk: tegra: Mark fuse clock as critical

2020-05-20 Thread Ben Hutchings

On Wed, 2020-05-20 at 15:14 +0100, Ben Hutchings wrote:
> 3.16.84-rc1 review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Stephen Warren 
> 
> commit bf83b96f87ae2abb1e535306ea53608e8de5dfbb upstream.

I've now dropped this, as CLK_IS_CRITICAL is not implemented on 3.16.

Ben.

> For a little over a year, U-Boot on Tegra124 has configured the flow
> controller to perform automatic RAM re-repair on off->on power
> transitions of the CPU rail[1]. This is mandatory for correct operation
> of Tegra124. However, RAM re-repair relies on certain clocks, which the
> kernel must enable and leave running. The fuse clock is one of those
> clocks. Mark this clock as critical so that LP1 power mode (system
> suspend) operates correctly.
> 
> [1] 3cc7942a4ae5 ARM: tegra: implement RAM repair
> 
> Reported-by: Jonathan Hunter 
> Signed-off-by: Stephen Warren 
> Signed-off-by: Thierry Reding 
> Signed-off-by: Ben Hutchings 
> ---
>  drivers/clk/tegra/clk-tegra-periph.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> --- a/drivers/clk/tegra/clk-tegra-periph.c
> +++ b/drivers/clk/tegra/clk-tegra-periph.c
> @@ -517,7 +517,11 @@ static struct tegra_periph_init_data gat
>   GATE("vcp", "clk_m", 29, 0, tegra_clk_vcp, 0),
>   GATE("apbdma", "clk_m", 34, 0, tegra_clk_apbdma, 0),
>   GATE("kbc", "clk_32k", 36, TEGRA_PERIPH_ON_APB | TEGRA_PERIPH_NO_RESET, 
> tegra_clk_kbc, 0),
> - GATE("fuse", "clk_m", 39, TEGRA_PERIPH_ON_APB, tegra_clk_fuse, 0),
> + /*
> +  * Critical for RAM re-repair operation, which must occur on resume
> +  * from LP1 system suspend and as part of CCPLEX cluster switching.
> +  */
> + GATE("fuse", "clk_m", 39, TEGRA_PERIPH_ON_APB, tegra_clk_fuse, 
> CLK_IS_CRITICAL),
>   GATE("fuse_burn", "clk_m", 39, TEGRA_PERIPH_ON_APB, 
> tegra_clk_fuse_burn, 0),
>   GATE("kfuse", "clk_m", 40, TEGRA_PERIPH_ON_APB, tegra_clk_kfuse, 0),
>   GATE("apbif", "clk_m", 107, TEGRA_PERIPH_ON_APB, tegra_clk_apbif, 0),
> 
-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken




signature.asc
Description: This is a digitally signed message part

Re: [PATCH net-next v2 2/4] net: phy: dp83869: Set opmode from straps

2020-05-20 Thread Florian Fainelli




On 5/20/2020 5:18 AM, Dan Murphy wrote:
> If the op-mode for the device is not set in the device tree then set
> the strapped op-mode and store it for later configuration.
> 
> Signed-off-by: Dan Murphy 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH v3] perf record: Use an eventfd to wakeup when done

2020-05-20 Thread Arnaldo Carvalho de Melo

Em Wed, May 13, 2020 at 01:39:41PM +0200, Jiri Olsa escreveu:
> On Wed, May 13, 2020 at 12:20:23PM +1000, Anand K Mistry wrote:
> > The setting and checking of 'done' contains a rare race where the signal
> > handler setting 'done' is run after checking to break the loop, but
> > before waiting in evlist__poll(). In this case, the main loop won't wake
> > up until either another signal is sent, or the perf data fd causes a
> > wake up.
> > 
> > The following simple script can trigger this condition (but you might
> > need to run it for several hours):
> > for ((i = 0; i >= 0; i++)) ; do
> >   echo "Loop $i"
> >   delay=$(echo "scale=4; 0.1 * $RANDOM/32768" | bc)
> >   ./perf record -- sleep 3000 >/dev/null&
> >   pid=$!
> >   sleep $delay
> >   kill -TERM $pid
> >   echo "PID $pid"
> >   wait $pid
> > done
> > 
> > At some point, the loop will stall. Adding logging, even though perf has
> > received the SIGTERM and set 'done = 1', perf will remain sleeping until
> > a second signal is sent.
> > 
> > Signed-off-by: Anand K Mistry 
> > 
> > ---
> > 
> > Changes in v3:
> > - Move done_fd creation to below session initialisation
> > - Close done_fd on exit
> > - Log errno when write(done_fd) fails
> 
> Acked-by: Jiri Olsa 

I've made this dependent on HAVE_EVENTFD_SUPPORT, so that it continues
building on older systems,

- Arnaldo

Re: [PATCH] arm64/cpufeature: Move BUG_ON() inside get_arm64_ftr_reg()

2020-05-20 Thread Catalin Marinas

On Wed, May 20, 2020 at 01:20:13PM +0100, Will Deacon wrote:
> On Wed, May 20, 2020 at 06:52:54AM +0530, Anshuman Khandual wrote:
> > There is no way to proceed when requested register could not be searched in
> > arm64_ftr_reg[]. Requesting for a non present register would be an error as
> > well. Hence lets just BUG_ON() when the search fails in get_arm64_ftr_reg()
> > rather than checking for return value and doing the same in some individual
> > callers.
> > 
> > But there are some callers that dont BUG_ON() upon search failure. It adds
> > an argument 'failsafe' that provides required switch between callers based
> > on whether they could proceed or not.
> > 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Suzuki K Poulose 
> > Cc: Mark Brown 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > 
> > Signed-off-by: Anshuman Khandual 
> > ---
> > Applies on next-20200518 that has recent cpufeature changes from Will.
> > 
> >  arch/arm64/kernel/cpufeature.c | 26 +-
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index bc5048f152c1..62767cc540c3 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -557,7 +557,7 @@ static int search_cmp_ftr_reg(const void *id, const 
> > void *regp)
> >   * - NULL on failure. It is upto the caller to decide
> >   *  the impact of a failure.
> >   */
> > -static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id)
> > +static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id, bool failsafe)
> 
> Generally, I'm not a big fan of boolean arguments because they are really
> opaque at the callsite. It also seems bogus to me that we don't trust the
> caller to pass a valid sys_id, but we trust it to get "failsafe" right,
> which seems to mean "I promise to check the result isn't NULL before
> dereferencing it."
> 
> So I don't see how this patch improves anything. I'd actually be more
> inclined to stick a WARN() in get_arm64_ftr_reg() when it returns NULL and
> have the callers handle NULL by returning early, getting rid of all the
> BUG_ONs in here. Sure, the system might end up in a funny state, but we
> WARN()d about it and tried to keep going (and Linus has some strong opinions
> on this too).

Such WARN can be triggered by the user via emulate_sys_reg(), so we
can't really have it in get_arm64_ftr_reg() without a 'failsafe' option.

-- 
Catalin

[rcu:rcu/next] BUILD SUCCESS 5b60c7d6d6e85e40289158d1347527f7a55cee40

2020-05-20 Thread kbuild test robot

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  rcu/next
branch HEAD: 5b60c7d6d6e85e40289158d1347527f7a55cee40  rcu: Mark 
rcu_nmi_enter() call to rcu_cleanup_after_idle() noinstr

elapsed time: 592m

configs tested: 92
configs skipped: 1

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
mips allyesconfig
m68k allyesconfig
i386 allyesconfig
i386defconfig
i386  debian-10.3
i386  allnoconfig
ia64 allmodconfig
ia64defconfig
ia64  allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k  allnoconfig
m68k   sun3_defconfig
m68kdefconfig
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  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc  defconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
x86_64   randconfig-a003-20200519
x86_64   randconfig-a005-20200519
x86_64   randconfig-a004-20200519
x86_64   randconfig-a006-20200519
x86_64   randconfig-a002-20200519
x86_64   randconfig-a001-20200519
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
x86_64  defconfig
sparcallyesconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
um   allmodconfig
x86_64   rhel
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25
x86_64  kexec

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

Re: [PATCH] hwrng: ks-sa - fix runtime pm imbalance on error

2020-05-20 Thread Sverdlin, Alexander (Nokia - DE/Ulm)

Hello Dinghao,

On Wed, 2020-05-20 at 21:29 +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.

I believe, this is the wrong place for such kind of fix.
pm_runtime_get_sync() has obviously a broken semantics with regards to
your observation but no other driver does what you propose.
I think the proper fix belong into PM subsystem, please take a look
onto commit 15bcb91d7e60 "PM / Runtime: Implement autosuspend support".

> Signed-off-by: Dinghao Liu 
> ---
>  drivers/char/hw_random/ks-sa-rng.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/char/hw_random/ks-sa-rng.c 
> b/drivers/char/hw_random/ks-sa-rng.c
> index e2330e757f1f..85c81da4a8af 100644
> --- a/drivers/char/hw_random/ks-sa-rng.c
> +++ b/drivers/char/hw_random/ks-sa-rng.c
> @@ -244,6 +244,7 @@ static int ks_sa_rng_probe(struct platform_device *pdev)
>   ret = pm_runtime_get_sync(dev);
>   if (ret < 0) {
>   dev_err(dev, "Failed to enable SA power-domain\n");
> + pm_runtime_put_sync(dev);
>   pm_runtime_disable(dev);
>   return ret;
>   }
-- 
Alexander Sverdlin.

[PATCH v8 5/5] dt-bindings: arm: fsl: add different Protonic boards

Add Protonic PRTI6Q, WD2, RVT, VT7 boards.

Signed-off-by: Oleksij Rempel 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index cd3fbe7e39487..a1657505b3357 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -119,6 +119,8 @@ properties:
   - fsl,imx6q-sabreauto
   - fsl,imx6q-sabrelite
   - fsl,imx6q-sabresd
+  - prt,prti6q# Protonic PRTI6Q board
+  - prt,prtwd2# Protonic WD2 board
   - technexion,imx6q-pico-dwarf   # TechNexion i.MX6Q Pico-Dwarf
   - technexion,imx6q-pico-hobbit  # TechNexion i.MX6Q Pico-Hobbit
   - technexion,imx6q-pico-nymph   # TechNexion i.MX6Q Pico-Nymph
@@ -170,6 +172,8 @@ properties:
   - emtrion,emcon-mx6-avari   # emCON-MX6S or emCON-MX6DL SoM on 
Avari Base
   - fsl,imx6dl-sabreauto  # i.MX6 DualLite/Solo SABRE 
Automotive Board
   - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device 
Board
+  - prt,prtrvt# Protonic RVT board
+  - prt,prtvt7# Protonic VT7 board
   - technexion,imx6dl-pico-dwarf   # TechNexion i.MX6DL Pico-Dwarf
   - technexion,imx6dl-pico-hobbit  # TechNexion i.MX6DL Pico-Hobbit
   - technexion,imx6dl-pico-nymph   # TechNexion i.MX6DL Pico-Nymph
-- 
2.26.2

[PATCH v8 4/5] ARM: dts: add Protonic RVT board

Protonic RVT is an internal development platform for a wireless ISObus
Virtual Terminal based on COTS tablets, and the predecessor of the WD2
platform.

Reviewed-by: Rob Herring 
Signed-off-by: David Jander 
Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/imx6dl-prtrvt.dts | 182 
 2 files changed, 183 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 66ee89e7929f9..89842a034e4ba 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -450,6 +450,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+   imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-prtrvt.dts 
b/arch/arm/boot/dts/imx6dl-prtrvt.dts
new file mode 100644
index 0..b7721e52a463a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-prtrvt.dts
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include 
+
+/ {
+   model = "Protonic RVT board";
+   compatible = "prt,prtrvt", "fsl,imx6dl";
+
+   memory@1000 {
+   device_type = "memory";
+   reg = <0x1000 0x1000>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_leds>;
+
+   led-debug0 {
+   function = LED_FUNCTION_STATUS;
+   gpios = < 8 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+};
+
+ {
+   pinctrl-0 = <_can1 _can1phy>;
+};
+
+ {
+   cs-gpios = < 19 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_ecspi1>;
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+};
+
+ {
+   cs-gpios = < 24 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_ecspi3>;
+   status = "okay";
+
+   nfc@0 {
+   compatible = "ti,trf7970a";
+   reg = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_nfc>;
+   spi-max-frequency = <200>;
+   interrupts-extended = < 14 IRQ_TYPE_LEVEL_LOW>;
+   ti,enable-gpios = < 12 GPIO_ACTIVE_LOW>,
+ < 11 GPIO_ACTIVE_LOW>;
+   vin-supply = <_3v3>;
+   vin-voltage-override = <310>;
+   autosuspend-delay = <3>;
+   irq-status-read-quirk;
+   en2-rf-quirk;
+   t5t-rmb-extra-byte-quirk;
+   status = "okay";
+   };
+};
+
+ {
+   adc@49 {
+   compatible = "ti,ads1015";
+   reg = <0x49>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* nc */
+   channel@4 {
+   reg = <4>;
+   ti,gain = <3>;
+   ti,datarate = <3>;
+   };
+
+   /* nc */
+   channel@5 {
+   reg = <5>;
+   ti,gain = <3>;
+   ti,datarate = <3>;
+   };
+
+   /* can1_l */
+   channel@6 {
+   reg = <6>;
+   ti,gain = <3>;
+   ti,datarate = <3>;
+   };
+
+   /* can1_h */
+   channel@7 {
+   reg = <7>;
+   ti,gain = <3>;
+   ti,datarate = <3>;
+   };
+   };
+
+   rtc@51 {
+   compatible = "nxp,pcf8563";
+   reg = <0x51>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   pinctrl_can1phy: can1phy {
+   fsl,pins = <
+   /* CAN1_SR */
+   MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+   /* CAN1_TERM */
+   MX6QDL_PAD_GPIO_0__GPIO1_IO00   0x1b0b0
+   >;
+   };
+
+   pinctrl_ecspi1: ecspi1grp {
+   fsl,pins = <
+   MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+   MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+   MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+   /* CS */
+   MX6QDL_PAD_EIM_D19__GPIO3_IO19  0x000b1
+

[PATCH v8 2/5] ARM: dts: add Protonic WD2 board

Add support for the Protonic WD2 board, which is an internal development
platform for low-cost agricultural Virtual Terminals based on COTS tablets
and web applications.
It inherits from the PRTI6Q base class.

Reviewed-by: Rob Herring 
Signed-off-by: David Jander 
Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/imx6q-prtwd2.dts | 188 +
 2 files changed, 189 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-prtwd2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 206a36a50575e..8ce744f1cbfc9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -539,6 +539,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-pico-pi.dtb \
imx6q-pistachio.dtb \
imx6q-prti6q.dtb \
+   imx6q-prtwd2.dtb \
imx6q-rex-pro.dtb \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6q-prtwd2.dts 
b/arch/arm/boot/dts/imx6q-prtwd2.dts
new file mode 100644
index 0..fd9f457a273e2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-prtwd2.dts
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2018 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include 
+
+/ {
+   model = "Protonic WD2 board";
+   compatible = "prt,prtwd2", "fsl,imx6q";
+
+   memory@1000 {
+   device_type = "memory";
+   reg = <0x1000 0x2000>;
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x8000 0x2000>;
+   };
+
+   usdhc2_wifi_pwrseq: usdhc2_wifi_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <_wifi_npd>;
+   reset-gpios = < 10 GPIO_ACTIVE_LOW>;
+   };
+
+   /* PRTWD2 rev 1 bitbang I2C for Ethernet Switch */
+   i2c@4 {
+   compatible = "i2c-gpio";
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c4>;
+   sda-gpios = < 22 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+   scl-gpios = < 31 GPIO_ACTIVE_HIGH>;
+   i2c-gpio,delay-us = <20>;   /* ~10 kHz */
+   i2c-gpio,scl-output-only;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+};
+
+ {
+   pinctrl-0 = <_can1 _can1phy>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_enet>;
+   phy-mode = "rmii";
+   clocks = < IMX6QDL_CLK_ENET>,
+< IMX6QDL_CLK_ENET>;
+   clock-names = "ipg", "ahb";
+   status = "okay";
+
+   fixed-link {
+   speed = <100>;
+   pause;
+   full-duplex;
+   };
+};
+
+ {
+   adc@49 {
+   compatible = "ti,ads1015";
+   reg = <0x49>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* V in */
+   channel@4 {
+   reg = <4>;
+   ti,gain = <1>;
+   ti,datarate = <3>;
+   };
+
+   /* I charge */
+   channel@5 {
+   reg = <5>;
+   ti,gain = <1>;
+   ti,datarate = <3>;
+   };
+
+   /* V bus  */
+   channel@6 {
+   reg = <6>;
+   ti,gain = <1>;
+   ti,datarate = <3>;
+   };
+
+   /* nc */
+   channel@7 {
+   reg = <7>;
+   ti,gain = <1>;
+   ti,datarate = <3>;
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_usdhc2>;
+   non-removable;
+   no-1-8-v;
+   non-removable;
+   mmc-pwrseq = <_wifi_pwrseq>;
+   pm-ignore-notify;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   wifi@1 {
+   compatible = "brcm,bcm4329-fmac";
+   reg = <1>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_eth_chg>;
+
+   pinctrl_can1phy: can1phy {
+   fsl,pins = <
+   /* CAN1_SR */
+   MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+   >;
+   };
+
+   pinctrl_enet: enetgrp {
+   fsl,pins = <
+   /* MX6QDL_ENET_PINGRP4 */
+   MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
+   MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
+   MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER   0x130b0
+   MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN   0x1b0b0
+   MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
+   MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1

[PATCH v8 3/5] ARM: dts: add Protonic VT7 board

The Protonic VT7 is a mid-class ISObus Virtual Terminal with a 7 inch
touchscreen display.

Reviewed-by: Rob Herring 
Signed-off-by: Robin van der Gracht 
Signed-off-by: David Jander 
Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/imx6dl-prtvt7.dts | 411 
 2 files changed, 412 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8ce744f1cbfc9..66ee89e7929f9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -450,6 +450,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+   imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
imx6dl-sabreauto.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts 
b/arch/arm/boot/dts/imx6dl-prtvt7.dts
new file mode 100644
index 0..083eb72f5fc3d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2016 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include 
+#include 
+#include 
+
+/ {
+   model = "Protonic VT7";
+   compatible = "prt,prtvt7", "fsl,imx6dl";
+
+   memory@1000 {
+   device_type = "memory";
+   reg = <0x1000 0x2000>;
+   };
+
+   backlight_lcd: backlight-lcd {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight>;
+   pwms = < 0 50>;
+   brightness-levels = <0 20 81 248 1000>;
+   default-brightness-level = <20>;
+   num-interpolated-steps = <21>;
+   power-supply = <_bl_12v0>;
+   enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
+   };
+
+   keys {
+   compatible = "gpio-keys";
+   autorepeat;
+
+   esc {
+   label = "GPIO Key ESC";
+   linux,code = ;
+   gpios = <_pca 0 GPIO_ACTIVE_LOW>;
+   };
+
+   up {
+   label = "GPIO Key UP";
+   linux,code = ;
+   gpios = <_pca 1 GPIO_ACTIVE_LOW>;
+   };
+
+   down {
+   label = "GPIO Key DOWN";
+   linux,code = ;
+   gpios = <_pca 4 GPIO_ACTIVE_LOW>;
+   };
+
+   enter {
+   label = "GPIO Key Enter";
+   linux,code = ;
+   gpios = <_pca 3 GPIO_ACTIVE_LOW>;
+   };
+
+   cycle {
+   label = "GPIO Key CYCLE";
+   linux,code = ;
+   gpios = <_pca 2 GPIO_ACTIVE_LOW>;
+   };
+
+   f1 {
+   label = "GPIO Key F1";
+   linux,code = ;
+   gpios = <_pca 14 GPIO_ACTIVE_LOW>;
+   };
+
+   f2 {
+   label = "GPIO Key F2";
+   linux,code = ;
+   gpios = <_pca 13 GPIO_ACTIVE_LOW>;
+   };
+
+   f3 {
+   label = "GPIO Key F3";
+   linux,code = ;
+   gpios = <_pca 12 GPIO_ACTIVE_LOW>;
+   };
+
+   f4 {
+   label = "GPIO Key F4";
+   linux,code = ;
+   gpios = <_pca 11 GPIO_ACTIVE_LOW>;
+   };
+
+   f5 {
+   label = "GPIO Key F5";
+   linux,code = ;
+   gpios = <_pca 10 GPIO_ACTIVE_LOW>;
+   };
+
+   f6 {
+   label = "GPIO Key F6";
+   linux,code = ;
+   gpios = <_pca 5 GPIO_ACTIVE_LOW>;
+   };
+
+   f7 {
+   label = "GPIO Key F7";
+   linux,code = ;
+   gpios = <_pca 6 GPIO_ACTIVE_LOW>;
+   };
+
+   f8 {
+   label = "GPIO Key F8";
+   linux,code = ;
+   gpios = <_pca 7 GPIO_ACTIVE_LOW>;
+   };
+
+   f9 {
+   label = "GPIO Key F9";
+   linux,code = ;
+   gpios = <_pca 8 GPIO_ACTIVE_LOW>;
+   };
+
+   f10 {
+   label = "GPIO Key F10";
+   linux,code = ;
+   gpios = <_pca 9 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+

[PATCH v8 0/5] mainline Protonic boards

changes v8:
- resend correct changes

changes v7:
- VT7: reorder node alphabetically
- VT7: rename "reg_12v_bl: regulator-bl-12v" to "reg_bl_12v0: regulator-bl-12v0"
- VT7: remove panel and TS nodes. This drivers are currently not
  mainline.
- prti6q.dtsi: move reg_1v8 to prti6q.dts
- prti6q.dtsi: remove pinctrl from the can1 node. It is done on almost
  every board file.

changes v6:
- move fsl.yaml changes to separate patch
- remove partitions, they are provided by the bootloader
- update flash compatible
- rename can3 to can
- fix fsl,mode
- fix interrupt in the wlan node on PRTI6Q

changes v5:
- PRTI6Q: remove status from the pwm-backlight node
- drop the vendor-prefixes patch, it is already taken by Rob
- add Reviewed-by: Rob Herring 

changes v4:
- VT7: fix typo

changes v3:
- move compatible to the start of node
- move status to the end
- use generic names in compatible
- refactor dts/dtsi
- use alphabet order for pinctrl and phandels
- remove unused or currently not supported nodes

changes v2:
- squash PRTI6Q patches

Oleksij Rempel (5):
  ARM: dts: add Protonic PRTI6Q board
  ARM: dts: add Protonic WD2 board
  ARM: dts: add Protonic VT7 board
  ARM: dts: add Protonic RVT board
  dt-bindings: arm: fsl: add different Protonic boards

 .../devicetree/bindings/arm/fsl.yaml  |   4 +
 arch/arm/boot/dts/Makefile|   4 +
 arch/arm/boot/dts/imx6dl-prtrvt.dts   | 182 ++
 arch/arm/boot/dts/imx6dl-prtvt7.dts   | 411 +
 arch/arm/boot/dts/imx6q-prti6q.dts| 541 ++
 arch/arm/boot/dts/imx6q-prtwd2.dts| 188 ++
 arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 165 ++
 7 files changed, 1495 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts
 create mode 100644 arch/arm/boot/dts/imx6q-prti6q.dts
 create mode 100644 arch/arm/boot/dts/imx6q-prtwd2.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-prti6q.dtsi

-- 
2.26.2

Re: clock_gettime64 vdso bug on 32-bit arm, rpi-4

2020-05-20 Thread Szabolcs Nagy

The 05/19/2020 22:31, Arnd Bergmann wrote:
> On Tue, May 19, 2020 at 10:24 PM Adhemerval Zanella
>  wrote:
> > On 19/05/2020 16:54, Arnd Bergmann wrote:
> > > Jack Schmidt reported a bug for the arm32 clock_gettimeofday64 vdso call 
> > > last
> > > month: https://github.com/richfelker/musl-cross-make/issues/96 and
> > > https://github.com/raspberrypi/linux/issues/3579
> > >
> > > As Will Deacon pointed out, this was never reported on the mailing list,
> > > so I'll try to summarize what we know, so this can hopefully be resolved 
> > > soon.
> > >
> > > - This happened reproducibly on Linux-5.6 on a 32-bit Raspberry Pi patched
> > >kernel running on a 64-bit Raspberry Pi 4b (bcm2711) when calling
> > >clock_gettime64(CLOCK_REALTIME)
> >
> > Does it happen with other clocks as well?
> 
> Unclear.
> 
> > > - The kernel tree is at https://github.com/raspberrypi/linux/, but I could
> > >   see no relevant changes compared to a mainline kernel.
> >
> > Is this bug reproducible with mainline kernel or mainline kernel can't be
> > booted on bcm2711?
> 
> Mainline linux-5.6 should boot on that machine but might not have
> all the other features, so I think users tend to use the raspberry pi
> kernel sources for now.
> 
> > > - From the report, I see that the returned time value is larger than the
> > >   expected time, by 3.4 to 14.5 million seconds in four samples, my
> > >   guess is that a random number gets added in at some point.
> >
> > What kind code are you using to reproduce it? It is threaded or issue
> > clock_gettime from signal handlers?
> 
> The reproducer is very simple without threads or signals,
> see the start of https://github.com/richfelker/musl-cross-make/issues/96
> 
> It does rely on calling into the musl wrapper, not the direct vdso
> call.
> 
> > > - From other sources, I found that the Raspberry Pi clocksource runs
> > >   at 54 MHz, with a mask value of 0xff. From these numbers
> > >   I would expect that reading a completely random hardware register
> > >   value would result in an offset up to 1.33 billion seconds, which is
> > >   around factor 100 more than the error we see, though similar.
> > >
> > > - The test case calls the musl clock_gettime() function, which falls back 
> > > to
> > >   the clock_gettime64() syscall on kernels prior to 5.5, or to the 32-bit
> > >   clock_gettime() prior to Linux-5.1. As reported in the bug, Linux-4.19 
> > > does
> > >   not show the bug.
> > >
> > > - The behavior was not reproduced on the same user space in qemu,
> > >   though I cannot tell whether the exact same kernel binary was used.
> > >
> > > - glibc-2.31 calls the same clock_gettime64() vdso function on arm to
> > >   implement clock_gettime(), but earlier versions did not. I have not
> > >   seen any reports of this bug, which could be explained by users
> > >   generally being on older versions.
> > >
> > > - As far as I can tell, there are no reports of this bug from other users,
> > >   and so far nobody could reproduce it.

note: i could not reproduce it in qemu-system with these configs:

qemu-system-aarch64 + arm64 kernel + compat vdso
qemu-system-aarch64 + kvm accel (on cortex-a72) + 32bit arm kernel
qemu-system-arm + cpu max + 32bit arm kernel

so i think it's something specific to that user's setup
(maybe rpi hw bug or gcc miscompiled the vdso or something
with that particular linux, i built my own linux 5.6 because
i did not know the exact kernel version where the bug was seen)

i don't have access to rpi (or other cortex-a53 where i
can install my own kernel) so this is as far as i got.

> > >
> > > - The current musl git tree has been patched to not call clock_gettime64
> > >on ARM because of this problem, so it cannot be used for reproducing 
> > > it.
> >
> > So should glibc follow musl and remove arm clock_gettime6y4 vDSO support
> > or this bug is localized to an specific kernel version running on an
> > specific hardware?
> 
> I hope we can figure out what is actually going on soon, there is probably
> no need to change glibc before we have.
> 
>   Arnd

--

[PATCH v8 1/5] ARM: dts: add Protonic PRTI6Q board