[PATCH v5] pci: dwc: dra7xx: Add shutdown handler to cleanly turn off clocks

[Keerthy]

Add shutdown handler to cleanly turn off clocks. This will help
in cases of kexec where in a new kernel can boot abruptly.

Signed-off-by: Keerthy 
Acked-by: Kishon Vijay Abraham I 
---

Changes in v5:

  * Declared the dra7xx_pcie_shutdown function static

Changes in v4:

  * Added the missing changes from v2!

Changes in v3:

  * Pushed the function outside #ifdef CONFIG_PM_SLEEP.
  * Added more details to commit log.

Changes in v2:

  * used a local dev pointer instead of dereferencing dev at multiple places.
  * dra7xx_pcie_stop_link before disabling clks in the shutdown path.

 drivers/pci/dwc/pci-dra7xx.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index 34427a6..d084800 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -794,6 +794,22 @@ static int dra7xx_pcie_resume_noirq(struct device *dev)
 }
 #endif
 
+static void dra7xx_pcie_shutdown(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
+   int ret;
+
+   dra7xx_pcie_stop_link(dra7xx->pci);
+
+   ret = pm_runtime_put_sync(dev);
+   if (ret < 0)
+   dev_dbg(dev, "pm_runtime_put_sync failed\n");
+
+   pm_runtime_disable(dev);
+   dra7xx_pcie_disable_phy(dra7xx);
+}
+
 static const struct dev_pm_ops dra7xx_pcie_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dra7xx_pcie_suspend, dra7xx_pcie_resume)
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(dra7xx_pcie_suspend_noirq,
@@ -807,5 +823,6 @@ static int dra7xx_pcie_resume_noirq(struct device *dev)
.suppress_bind_attrs = true,
.pm = _pcie_pm_ops,
},
+   .shutdown = dra7xx_pcie_shutdown,
 };
 builtin_platform_driver_probe(dra7xx_pcie_driver, dra7xx_pcie_probe);
-- 
1.9.1

Re: [PATCH v5 10/26] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass

[Christoffer Dall]

Hi Eric and Marc,

On Tue, Nov 07, 2017 at 02:42:44PM +, Marc Zyngier wrote:
> Hi Eric,
> 
> On 07/11/17 13:06, Auger Eric wrote:
> > Hi Marc,
> > 
> > On 27/10/2017 16:28, Marc Zyngier wrote:
> >> Let's use the irq bypass mechanism introduced for platform device
> >> interrupts
> > nit: I would remove "introduced for platform device interrupts"
> > as this is not upstream yet. x86 posted interrupts also use it.
> > 
> >>
> >  and establish our LPI->VLPI mapping.

I have tweaked the commit message.

> >>
> >> Reviewed-by: Christoffer Dall 
> >> Signed-off-by: Marc Zyngier 
> >> ---
> >>  include/kvm/arm_vgic.h  |   8 
> >>  virt/kvm/arm/arm.c  |   6 ++-
> >>  virt/kvm/arm/vgic/vgic-v4.c | 108 
> >> 
> >>  3 files changed, 120 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> >> index 7eeb6c2a2f9c..2f750c770bf2 100644
> >> --- a/include/kvm/arm_vgic.h
> >> +++ b/include/kvm/arm_vgic.h
> >> @@ -373,4 +373,12 @@ int kvm_vgic_setup_default_irq_routing(struct kvm 
> >> *kvm);
> >>  
> >>  int kvm_vgic_set_owner(struct kvm_vcpu *vcpu, unsigned int intid, void 
> >> *owner);
> >>  
> >> +struct kvm_kernel_irq_routing_entry;
> >> +
> >> +int kvm_vgic_v4_set_forwarding(struct kvm *kvm, int irq,
> >> + struct kvm_kernel_irq_routing_entry *irq_entry);
> >> +
> >> +int kvm_vgic_v4_unset_forwarding(struct kvm *kvm, int irq,
> >> +   struct kvm_kernel_irq_routing_entry 
> >> *irq_entry);
> >> +
> >>  #endif /* __KVM_ARM_VGIC_H */
> >> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> >> index 5d5218ecd547..8388c1cc23f6 100644
> >> --- a/virt/kvm/arm/arm.c
> >> +++ b/virt/kvm/arm/arm.c
> >> @@ -1462,7 +1462,8 @@ int kvm_arch_irq_bypass_add_producer(struct 
> >> irq_bypass_consumer *cons,
> >>struct kvm_kernel_irqfd *irqfd =
> >>container_of(cons, struct kvm_kernel_irqfd, consumer);
> >>  
> >> -  return 0;
> >> +  return kvm_vgic_v4_set_forwarding(irqfd->kvm, prod->irq,
> >> +>irq_entry);
> >>  }
> >>  void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
> >>  struct irq_bypass_producer *prod)
> >> @@ -1470,7 +1471,8 @@ void kvm_arch_irq_bypass_del_producer(struct 
> >> irq_bypass_consumer *cons,
> >>struct kvm_kernel_irqfd *irqfd =
> >>container_of(cons, struct kvm_kernel_irqfd, consumer);
> >>  
> >> -  return;
> >> +  kvm_vgic_v4_unset_forwarding(irqfd->kvm, prod->irq,
> >> +   >irq_entry);
> >>  }
> >>  
> >>  void kvm_arch_irq_bypass_stop(struct irq_bypass_consumer *cons)
> >> diff --git a/virt/kvm/arm/vgic/vgic-v4.c b/virt/kvm/arm/vgic/vgic-v4.c
> >> index c794f0cef09e..01a2889b7b7c 100644
> >> --- a/virt/kvm/arm/vgic/vgic-v4.c
> >> +++ b/virt/kvm/arm/vgic/vgic-v4.c
> >> @@ -18,6 +18,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  
> >>  #include "vgic.h"
> >>  
> >> @@ -81,3 +82,110 @@ void vgic_v4_teardown(struct kvm *kvm)
> >>its_vm->nr_vpes = 0;
> >>its_vm->vpes = NULL;
> >>  }
> >> +
> >> +static struct vgic_its *vgic_get_its(struct kvm *kvm,
> >> +   struct kvm_kernel_irq_routing_entry 
> >> *irq_entry)
> >> +{
> >> +  struct kvm_msi msi  = (struct kvm_msi) {
> >> +  .address_lo = irq_entry->msi.address_lo,
> >> +  .address_hi = irq_entry->msi.address_hi,
> >> +  .data   = irq_entry->msi.data,
> >> +  .flags  = irq_entry->msi.flags,
> >> +  .devid  = irq_entry->msi.devid,
> >> +  };
> >> +
> >> +  /*
> >> +   * Get a reference on the LPI. If NULL, this is not a valid
> >> +   * translation for any of our vITSs.
> >> +   */
> > I don't understand the relevance of the above comment.
> 
> Hmmm. The first part looks like an outdated leftover, as the ITS is not
> refcounted, and we don't deal with LPIs here.
> 

I simply removed this comment.

[...]

I think the only thing left to fix on this patch is the IRQ_DISABLE_LAZY
thing on its_map_vlpi() failures, which Marc can fix post -rc1.

Thanks,
-Christoffer

Re: [PATCH v5 09/26] KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain

[Marc Zyngier]

On 10/11/17 08:20, Christoffer Dall wrote:
> On Tue, Nov 07, 2017 at 02:08:23PM +0100, Auger Eric wrote:
>> Hi Marc,
>>
>> On 27/10/2017 16:28, Marc Zyngier wrote:
>>> In order to control the GICv4 view of virtual CPUs, we rely
>>> on an irqdomain allocated for that purpose. Let's add a couple
>>> of helpers to that effect.
>>>
>>> At the same time, the vgic data structures gain new fields to
>>> track all this... erm... wonderful stuff.
>>>
>>> The way we hook into the vgic init is slightly convoluted. We
>>> need the vgic to be initialized (in order to guarantee that
>>> the number of vcpus is now fixed), and we must have a vITS
>>> (otherwise this is all very pointless). So we end-up calling
>>> the init from both vgic_init and vgic_its_create.
>>>
>>> Reviewed-by: Christoffer Dall 
>>> Signed-off-by: Marc Zyngier 
>>> ---
>>>  arch/arm/kvm/Makefile |  1 +
>>>  arch/arm64/kvm/Makefile   |  1 +
>>>  include/kvm/arm_vgic.h| 19 ++
>>>  virt/kvm/arm/vgic/vgic-init.c |  9 +
>>>  virt/kvm/arm/vgic/vgic-its.c  |  8 +
>>>  virt/kvm/arm/vgic/vgic-v4.c   | 83 
>>> +++
>>>  virt/kvm/arm/vgic/vgic.h  |  2 ++
>>>  7 files changed, 123 insertions(+)
>>>  create mode 100644 virt/kvm/arm/vgic/vgic-v4.c
>>>
>>> diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
>>> index d9beee652d36..0a1dd2cdb928 100644
>>> --- a/arch/arm/kvm/Makefile
>>> +++ b/arch/arm/kvm/Makefile
>>> @@ -31,6 +31,7 @@ obj-y += $(KVM)/arm/vgic/vgic-init.o
>>>  obj-y += $(KVM)/arm/vgic/vgic-irqfd.o
>>>  obj-y += $(KVM)/arm/vgic/vgic-v2.o
>>>  obj-y += $(KVM)/arm/vgic/vgic-v3.o
>>> +obj-y += $(KVM)/arm/vgic/vgic-v4.o
>>>  obj-y += $(KVM)/arm/vgic/vgic-mmio.o
>>>  obj-y += $(KVM)/arm/vgic/vgic-mmio-v2.o
>>>  obj-y += $(KVM)/arm/vgic/vgic-mmio-v3.o
>>> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>>> index 5d9810086c25..c30fd388ef80 100644
>>> --- a/arch/arm64/kvm/Makefile
>>> +++ b/arch/arm64/kvm/Makefile
>>> @@ -26,6 +26,7 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-init.o
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-irqfd.o
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-v2.o
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-v3.o
>>> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-v4.o
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio.o
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v2.o
>>>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
>>> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>>> index ba9fb450aa1b..7eeb6c2a2f9c 100644
>>> --- a/include/kvm/arm_vgic.h
>>> +++ b/include/kvm/arm_vgic.h
>>> @@ -26,6 +26,8 @@
>>>  #include 
>>>  #include 
>>>  
>>> +#include 
>>> +
>>>  #define VGIC_V3_MAX_CPUS   255
>>>  #define VGIC_V2_MAX_CPUS   8
>>>  #define VGIC_NR_IRQS_LEGACY 256
>>> @@ -236,6 +238,15 @@ struct vgic_dist {
>>>  
>>> /* used by vgic-debug */
>>> struct vgic_state_iter *iter;
>>> +
>>> +   /*
>>> +* GICv4 ITS per-VM data, containing the IRQ domain, the VPE
>>> +* array, the property table pointer as well as allocation
>>> +* data. This essentially ties the Linux IRQ core and ITS
>>> +* together, and avoids leaking KVM's data structures anywhere
>>> +* else.
>>> +*/
>>> +   struct its_vm   its_vm;
>>>  };
>>>  
>>>  struct vgic_v2_cpu_if {
>>> @@ -254,6 +265,14 @@ struct vgic_v3_cpu_if {
>>> u32 vgic_ap0r[4];
>>> u32 vgic_ap1r[4];
>>> u64 vgic_lr[VGIC_V3_MAX_LRS];
>>> +
>>> +   /*
>>> +* GICv4 ITS per-VPE data, containing the doorbell IRQ, the
>>> +* pending table pointer, the its_vm pointer and a few other
>>> +* HW specific things. As for the its_vm structure, this is
>>> +* linking the Linux IRQ subsystem and the ITS together.
>>> +*/
>>> +   struct its_vpe  its_vpe;
>>>  };
>>>  
>>>  struct vgic_cpu {
>>> diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
>>> index 5801261f3add..40be908da238 100644
>>> --- a/virt/kvm/arm/vgic/vgic-init.c
>>> +++ b/virt/kvm/arm/vgic/vgic-init.c
>>> @@ -285,6 +285,12 @@ int vgic_init(struct kvm *kvm)
>>> if (ret)
>>> goto out;
>>>  
>>> +   if (vgic_supports_direct_msis(kvm)) {
>>> +   ret = vgic_v4_init(kvm);
>>> +   if (ret)
>>> +   goto out;
>>> +   }
>>> +
>>> kvm_for_each_vcpu(i, vcpu, kvm)
>>> kvm_vgic_vcpu_enable(vcpu);
>>>  
>>> @@ -320,6 +326,9 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
>>>  
>>> kfree(dist->spis);
>>> dist->nr_spis = 0;
>>> +
>>> +   if (vgic_supports_direct_msis(kvm))
>>> +   vgic_v4_teardown(kvm);
>>>  }
>>>  
>>>  void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
>>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
>>> index 8ee03f1e89fc..89768d2b6a91 100644
>>> --- 

RE: [PATCH] PCI: hv: use effective affinity mask

[Adrian Suhov (Cloudbase Solutions SRL)]

Hi,

I've also tested this and it's working good. Kernels tested:
 - next-20171109 on top of Ubuntu 16.04
 - MSFT kernel - 4.14.0-rc5 with patch applied - on top of RHEL 7.3

Adrian

-Original Message-
From: Bjorn Helgaas [mailto:helg...@kernel.org] 
Sent: Wednesday, November 8, 2017 3:08 AM
To: Dexuan Cui 
Cc: Bjorn Helgaas ; linux-...@vger.kernel.org; Jake Oshins 
; KY Srinivasan ; Stephen Hemminger 
; de...@linuxdriverproject.org; 
linux-kernel@vger.kernel.org; Haiyang Zhang ; Jork 
Loeser ; Chris Valean (Cloudbase Solutions SRL) 
; Adrian Suhov (Cloudbase Solutions SRL) 
; Simon Xiao ; 'Eyal Mizrachi' 
; Jack Morgenstein ; Armen Guezalian 
; Firas Mahameed ; Tziporet Koren 
; Daniel Jurgens 
Subject: Re: [PATCH] PCI: hv: use effective affinity mask

On Wed, Nov 01, 2017 at 08:30:53PM +, Dexuan Cui wrote:
> 
> The effective_affinity_mask is always set when an interrupt is 
> assigned in
> __assign_irq_vector() -> apic->cpu_mask_to_apicid(), e.g. for struct 
> apic
> apic_physflat: -> default_cpu_mask_to_apicid() -> 
> irq_data_update_effective_affinity(), but it looks d->common->affinity 
> remains all-1's before the user space or the kernel changes it later.
> 
> In the early allocation/initialization phase of an irq, we should use 
> the effective_affinity_mask, otherwise Hyper-V may not deliver the 
> interrupt to the expected cpu. Without the patch, if we assign 7 
> Mellanox ConnectX-3 VFs to a 32-vCPU VM, one of the VFs may fail to receive 
> interrupts.
> 
> Signed-off-by: Dexuan Cui 
> Cc: Jake Oshins 
> Cc: Jork Loeser 
> Cc: Stephen Hemminger 
> Cc: K. Y. Srinivasan 
> ---
> 
> Please consider this for v4.14, if it's not too late.

What would be the rationale for putting it in v4.14?  After the merge window, I 
usually only merge fixes for problems introduced during the merge window, or 
for serious regressions.  I can't tell if this fits into that or not.

>  drivers/pci/host/pci-hyperv.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c 
> b/drivers/pci/host/pci-hyperv.c index 5ccb47d..8b5f66d 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -879,7 +879,7 @@ static void hv_irq_unmask(struct irq_data *data)
>   int cpu;
>   u64 res;
>  
> - dest = irq_data_get_affinity_mask(data);
> + dest = irq_data_get_effective_affinity_mask(data);
>   pdev = msi_desc_to_pci_dev(msi_desc);
>   pbus = pdev->bus;
>   hbus = container_of(pbus->sysdata, struct hv_pcibus_device, 
> sysdata); @@ -1042,6 +1042,7 @@ static void hv_compose_msi_msg(struct 
> irq_data *data, struct msi_msg *msg)
>   struct hv_pci_dev *hpdev;
>   struct pci_bus *pbus;
>   struct pci_dev *pdev;
> + struct cpumask *dest;
>   struct compose_comp_ctxt comp;
>   struct tran_int_desc *int_desc;
>   struct {
> @@ -1056,6 +1057,7 @@ static void hv_compose_msi_msg(struct irq_data *data, 
> struct msi_msg *msg)
>   int ret;
>  
>   pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
> + dest = irq_data_get_effective_affinity_mask(data);
>   pbus = pdev->bus;
>   hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata);
>   hpdev = get_pcichild_wslot(hbus, devfn_to_wslot(pdev->devfn)); @@ 
> -1081,14 +1083,14 @@ static void hv_compose_msi_msg(struct irq_data *data, 
> struct msi_msg *msg)
>   switch (pci_protocol_version) {
>   case PCI_PROTOCOL_VERSION_1_1:
>   size = hv_compose_msi_req_v1(_pkts.v1,
> - irq_data_get_affinity_mask(data),
> + dest,
>   hpdev->desc.win_slot.slot,
>   cfg->vector);
>   break;
>  
>   case PCI_PROTOCOL_VERSION_1_2:
>   size = hv_compose_msi_req_v2(_pkts.v2,
> - irq_data_get_affinity_mask(data),
> + dest,
>   hpdev->desc.win_slot.slot,
>   cfg->vector);
>   break;
> --
> 2.7.4
> 

Re: [PATCH 15/15] wait_bit: introduce {wait_on,wake_up}_devmap_idle

[Christoph Hellwig]

On Tue, Oct 31, 2017 at 04:22:56PM -0700, Dan Williams wrote:
> Add hashed waitqueue infrastructure to wait for ZONE_DEVICE pages to
> drop their reference counts and be considered idle for DMA. This
> facility will be used for filesystem callbacks / wakeups when DMA to a
> DAX mapped range of a file ends.
> 
> For now, this implementation does not have functional behavior change
> outside of waking waitqueues that do not have any waiters present.

Hmm.  What is the point of the patch then?

You also probably want to split this into one well documented patch
that changes the bit wait infrastructure and another one using it.

Re: [PATCH v2 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Ulf Hansson]

On 8 November 2017 at 14:25, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
> instruct the PM core and middle-layer (bus type, PM domain, etc.)
> code that it is desirable to leave the device in runtime suspend
> after system-wide transitions to the working state (for example,
> the device may be slow to resume and it may be better to avoid
> resuming it right away).
>
> Generally, the middle-layer code involved in the handling of the
> device is expected to indicate to the PM core whether or not the
> device may be left in suspend with the help of the device's
> power.may_skip_resume status bit.  That has to happen in the "noirq"
> phase of the preceding system suspend (or analogous) transition.
> The middle layer is then responsible for handling the device as
> appropriate in its "noirq" resume callback which is executed
> regardless of whether or not the device may be left suspended, but
> the other resume callbacks (except for ->complete) will be skipped
> automatically by the core if the device really can be left in
> suspend.

I don't understand the reason to why you need to skip invoking resume
callbacks to achieve this behavior, could you elaborate on that?

Couldn't the PM domain or the middle-layer instead decide what to do?
To me it sounds a bit prone to errors by skipping callbacks from the
PM core, and I wonder if the general driver author will be able to
understand how to use this flag properly.

That said, as the series don't include any changes for drivers making
use of the flag, could please fold in such change as it would provide
a more complete picture?

>
> The additional power.must_resume status bit introduced for the
> implementation of this mechanisn is used internally by the PM core
> to track the requirement to resume the device (which may depend on
> its children etc).

Yeah, clearly the PM core needs to be involved, because of the need of
dealing with parent/child relations, however as kind of indicate
above, couldn't the PM core just set some flag/status bits, which
instructs the middle-layer and PM domain on what to do? That sounds
like an easier approach.

>
> Signed-off-by: Rafael J. Wysocki 
> Acked-by: Greg Kroah-Hartman 
> ---
>  Documentation/driver-api/pm/devices.rst |   24 ++-
>  drivers/base/power/main.c   |   65 
> +---
>  include/linux/pm.h  |   14 +-
>  3 files changed, 93 insertions(+), 10 deletions(-)
>
> Index: linux-pm/include/linux/pm.h
> ===
> --- linux-pm.orig/include/linux/pm.h
> +++ linux-pm/include/linux/pm.h
> @@ -559,6 +559,7 @@ struct pm_subsys_data {
>   * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
>   * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
>   * SMART_SUSPEND: No need to resume the device from runtime suspend.
> + * LEAVE_SUSPENDED: Avoid resuming the device during system resume if 
> possible.
>   *
>   * Setting SMART_PREPARE instructs bus types and PM domains which may want
>   * system suspend/resume callbacks to be skipped for the device to return 0 
> from
> @@ -572,10 +573,14 @@ struct pm_subsys_data {
>   * necessary from the driver's perspective.  It also may cause them to skip
>   * invocations of the ->suspend_late and ->suspend_noirq callbacks provided 
> by
>   * the driver if they decide to leave the device in runtime suspend.
> + *
> + * Setting LEAVE_SUSPENDED informs the PM core and middle-layer code that the
> + * driver prefers the device to be left in runtime suspend after system 
> resume.
>   */
> -#define DPM_FLAG_NEVER_SKIPBIT(0)
> -#define DPM_FLAG_SMART_PREPARE BIT(1)
> -#define DPM_FLAG_SMART_SUSPEND BIT(2)
> +#define DPM_FLAG_NEVER_SKIPBIT(0)
> +#define DPM_FLAG_SMART_PREPARE BIT(1)
> +#define DPM_FLAG_SMART_SUSPEND BIT(2)
> +#define DPM_FLAG_LEAVE_SUSPENDED   BIT(3)
>
>  struct dev_pm_info {
> pm_message_tpower_state;
> @@ -597,6 +602,8 @@ struct dev_pm_info {
> boolwakeup_path:1;
> boolsyscore:1;
> boolno_pm_callbacks:1;  /* Owned by the PM 
> core */
> +   unsigned intmust_resume:1;  /* Owned by the PM core */
> +   unsigned intmay_skip_resume:1;  /* Set by subsystems 
> */
>  #else
> unsigned intshould_wakeup:1;
>  #endif
> @@ -765,6 +772,7 @@ extern int pm_generic_poweroff_late(stru
>  extern int pm_generic_poweroff(struct device *dev);
>  extern void pm_generic_complete(struct device *dev);
>
> +extern bool dev_pm_may_skip_resume(struct device *dev);
>  extern bool dev_pm_smart_suspend_and_suspended(struct device *dev);
>
>  #else /* 

Re: [PATCH V13 03/10] mmc: block: Add blk-mq support

[Linus Walleij]

Following up on this:

On Thu, Nov 9, 2017 at 4:52 PM, Linus Walleij  wrote:

>> No one has ever suggested that the legacy API will remain.  Once blk-mq is
>> ready the old code gets deleted.
>
> The block layer maintainers most definately think MQ is ready
> but you seem to disagree. Why?
>
> In the recent LWN article from kernel recepies:
> https://lwn.net/Articles/735275/
> the only obstacle I can see is a mention that SCSI was not
> switched over by default because of some problems with
> slow rotating media. "This change had to be backed out
> because of some performance and scalability issues that
> arose for rotating storage."
>
> Christoph mentions that he's gonna try again for v4.14.
> But it's true, I do not see that happening in linux-next yet.

Neil Brown's article on LWN points to Ming Lei's patch
set:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1513023.html

As addressing the issue that held back blk-MQ from
being default for SCSI, and it is reportedly to be
queued for v4.15. Since this MMC/SD rework is
also targeted for v4.15 I think we can assume it is
pretty much ready for everything, and delete the
non-MQ block path.

I just haven't seen any of this problem in my tests
with MMC/SD so I do not think it would be affected,
but it anyways seem to be fixed.

OK maybe I am especially optimistic. But it's not just
based on that.

Yours,
Linus Walleij

Re: [PATCH v2 3/3] HID: cp2112: fix broken gpio_direction_input callback

[Benjamin Tissoires]

On Nov 10 2017 or thereabouts, Sébastien Szymanski wrote:
> When everything goes smoothly, ret is set to 0 which makes the function
> to return EIO error.
> 
> Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
> Signed-off-by: Sébastien Szymanski 
> ---
> Changes in v2:
>  - rework error handling to have only one exit path as suggested by
>Benjamin Tissoires 

Looks good to me now. Thanks for the respin:
Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

> 
>  drivers/hid/hid-cp2112.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> index 28e3c18..68cdc96 100644
> --- a/drivers/hid/hid-cp2112.c
> +++ b/drivers/hid/hid-cp2112.c
> @@ -196,6 +196,8 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>HID_REQ_GET_REPORT);
>   if (ret != CP2112_GPIO_CONFIG_LENGTH) {
>   hid_err(hdev, "error requesting GPIO config: %d\n", ret);
> + if (ret >= 0)
> + ret = -EIO;
>   goto exit;
>   }
>  
> @@ -205,8 +207,10 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>   ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
>CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
>HID_REQ_SET_REPORT);
> - if (ret < 0) {
> + if (ret != CP2112_GPIO_CONFIG_LENGTH) {
>   hid_err(hdev, "error setting GPIO config: %d\n", ret);
> + if (ret >= 0)
> + ret = -EIO;
>   goto exit;
>   }
>  
> @@ -214,7 +218,7 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
> *chip, unsigned offset)
>  
>  exit:
>   mutex_unlock(>lock);
> - return ret < 0 ? ret : -EIO;
> + return ret;
>  }
>  
>  static void cp2112_gpio_set(struct gpio_chip *chip, unsigned offset, int 
> value)
> -- 
> 2.7.3
> 

Re: [PATCH net-next] bindings: net: stmmac: correctify note about LPI interrupt

[Alexandre Torgue]

On 11/09/2017 06:09 PM, Niklas Cassel wrote:

There are two different combined signal for various interrupt events:
In EQOS-CORE and EQOS-MTL configurations, mci_intr_o is the interrupt
signal.
In EQOS-DMA, EQOS-AHB and EQOS-AXI configurations, these interrupt events
are combined with the events in the DMA on the sbd_intr_o signal.

Depending on configuration, the device tree irq "macirq" will refer to
either mci_intr_o or sbd_intr_o.

The databook states:
"The MAC generates the LPI interrupt when the Tx or Rx side enters or exits
the LPI state. The interrupt mci_intr_o (sbd_intr_o in certain
configurations) is asserted when the LPI interrupt status is set.

When the MAC exits the Rx LPI state, then in addition to the mci_intr_o
(sbd_intr_o in certain configurations), the sideband signal lpi_intr_o is
asserted.

If you do not want to gate-off the application clock during the Rx LPI
state, you can leave the lpi_intr_o signal unconnected and use the
mci_intr_o (sbd_intr_o in certain configurations) signal to detect Rx LPI
exit."

Since the "macirq" is always raised when Tx or Rx enters/exits the LPI
state, "eth_lpi" must therefore refer to lpi_intr_o, which is only raised
when Rx exits the LPI state. Update the DT binding description to reflect
reality.

Signed-off-by: Niklas Cassel 
---
  Documentation/devicetree/bindings/net/stmmac.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index c3a7be6615c5..3a28a5d8857d 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -12,7 +12,7 @@ Required properties:
Valid interrupt names are:
- "macirq" (combined signal for various interrupt events)
- "eth_wake_irq" (the interrupt to manage the remote wake-up packet 
detection)
-  - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI state)
+  - "eth_lpi" (the interrupt that occurs when Rx exits the LPI state)
  - phy-mode: See ethernet.txt file in the same directory.
  - snps,reset-gpio gpio number for phy reset.
  - snps,reset-active-low boolean flag to indicate if phy reset is active low.


Acked-by: Alexandre TORGUE 

Re: [PATCH] gpio: davinci: Assign first bank regs for unbanked case

[Keerthy]

On Friday 10 November 2017 04:37 PM, Keerthy wrote:
> From: "J, KEERTHY" 

Linus,

The $Author field is somehow messed up. Please ignore. I will send v2
with this fixed.

Regards,
Keerthy

> 
> As per the re-design assign the first bank regs for unbanked
> irq case. This was missed out in the original patch.
> 
> Signed-off-by: Keerthy 
> Fixes: b5cf3fd827d2e1 ("gpio: davinci: Redesign driver to accommodate ngpios 
> in one gpio chip")
> ---
>  drivers/gpio/gpio-davinci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index f75d844..e4b3d7d 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -383,7 +383,7 @@ static int gpio_irq_type_unbanked(struct irq_data *data, 
> unsigned trigger)
>   u32 mask;
>  
>   d = (struct davinci_gpio_controller 
> *)irq_data_get_irq_handler_data(data);
> - g = (struct davinci_gpio_regs __iomem *)d->regs;
> + g = (struct davinci_gpio_regs __iomem *)d->regs[0];
>   mask = __gpio_mask(data->irq - d->base_irq);
>  
>   if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
> 

Re: [PATCH v3] kernel/kprobes: add re-register safe check for register_kretprobe()

[Masami Hiramatsu]

On Fri, 10 Nov 2017 17:28:33 +0800
JianKang Chen  wrote:

> From: Chen Jiankang 
> 
> When there are two same struct kretprobe rp, the INIT_HLIST_HEAD()
> will result in a empty list table rp->free_instances. The memory leak
> will happen. So it needs to add re-register safe check by
> __get_valid_kprobe().

Under rcu read lock :) Please see below comment.

> 
> However, current this is not safe for multi-threadings, because
> there is still a chance to re-register kretprobe concurrently.
> So I add a kretprobe_mutex lock to protect the INIT_LIST_HEAD;
> 
> Signed-off-by: Chen Jiankang 
> ---
>  kernel/kprobes.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index a1606a4..5ff8f69 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -67,6 +67,7 @@
>  
>  /* This protects kprobe_table and optimizing_list */
>  static DEFINE_MUTEX(kprobe_mutex);
> +static DEFINE_MUTEX(kretprobe_mutex);
>  static DEFINE_PER_CPU(struct kprobe *, kprobe_instance) = NULL;
>  static struct {
>   raw_spinlock_t lock cacheline_aligned_in_smp;
> @@ -1947,6 +1948,12 @@ int register_kretprobe(struct kretprobe *rp)
>   rp->maxactive = num_possible_cpus();
>  #endif
>   }
> +
> + mutex_lock(_mutex);
> + if (__get_valid_kprobe(>kp)) {

__get_valid_kprobe() must be called under rcu_read_lock or preempt disabled,
because it tracks down the rcu list.

Thank you.



> + ret = -EINVAL;
> + goto out;
> + }
>   raw_spin_lock_init(>lock);
>   INIT_HLIST_HEAD(>free_instances);
>   for (i = 0; i < rp->maxactive; i++) {
> @@ -1954,7 +1961,8 @@ int register_kretprobe(struct kretprobe *rp)
>  rp->data_size, GFP_KERNEL);
>   if (inst == NULL) {
>   free_rp_inst(rp);
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto out;
>   }
>   INIT_HLIST_NODE(>hlist);
>   hlist_add_head(>hlist, >free_instances);
> @@ -1965,6 +1973,8 @@ int register_kretprobe(struct kretprobe *rp)
>   ret = register_kprobe(>kp);
>   if (ret != 0)
>   free_rp_inst(rp);
> +out:
> + mutex_unlock(_mutex);
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(register_kretprobe);
> -- 
> 1.7.12.4
> 


-- 
Masami Hiramatsu 

[PATCH v2 00/14] soundwire: Add a new SoundWire subsystem

[Vinod Koul]

This patch series adds a new SoundWire subsystem which implements a
new MIPI bus protocol 'SoundWire'.

The SoundWire protocol is a robust, scalable, low complexity, low
power, low latency, two-pin (clock and data) multi-drop bus that
allows for the transfer of multiple audio streams and embedded
control/commands.  SoundWire provides synchronization capabilities
and supports both PCM and PDM, multichannel data, isochronous and
asynchronous modes.

This series adds SoundWire Bus, IO transfers, DisCo (Discovery and
Configuration) sysfs interface, regmap and Documentation summary

This patch series is also available on
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git topic/patch_v2

v1: https://lkml.org/lkml/2017/10/18/1030
RFC: https://lkml.org/lkml/2016/10/21/395

Changes in v2:
- move documentation into driver-api and do rst conversion
- fix documentation comments
- add SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) to all
  source files
- rework the transfer logic and paging logic as commented on v1
- remove dummy sysfs fns
- registration checks and fixes
- remove slave check for regamp as that turned superfluous
- remove depends SoundWire symbol
- make modalias api arg const
- use bitmap for tracking assigned
- add counter for report present tracking
todo: add the dt-bindings

Sanyog Kale (4):
  Documentation: Add SoundWire summary
  soundwire: Add SoundWire MIPI defined registers
  soundwire: Add Slave status handling helpers
  soundwire: cdns: Add sdw_master_ops and IO transfer support

Vinod Koul (10):
  soundwire: Add SoundWire bus type
  soundwire: Add Master registration
  soundwire: Add MIPI DisCo property helpers
  soundwire: Add IO transfer
  regmap: Add SoundWire bus support
  soundwire: Add slave status handling
  soundwire: Add sysfs for SoundWire DisCo properties
  soundwire: cdns: Add cadence library
  soundwire: intel: Add Intel Master driver
  soundwire: intel: Add Intel init module

 Documentation/driver-api/index.rst |1 +
 Documentation/driver-api/soundwire/index.rst   |   15 +
 Documentation/driver-api/soundwire/summary.rst |  205 +
 drivers/Kconfig|2 +
 drivers/Makefile   |1 +
 drivers/base/regmap/Kconfig|4 +
 drivers/base/regmap/Makefile   |1 +
 drivers/base/regmap/regmap-sdw.c   |  140 
 drivers/soundwire/Kconfig  |   36 +
 drivers/soundwire/Makefile |   18 +
 drivers/soundwire/bus.c| 1013 
 drivers/soundwire/bus.h|  126 +++
 drivers/soundwire/bus_type.c   |  245 ++
 drivers/soundwire/cadence_master.c |  791 ++
 drivers/soundwire/cadence_master.h |   96 +++
 drivers/soundwire/intel.c  |  391 +
 drivers/soundwire/intel.h  |   72 ++
 drivers/soundwire/intel_init.c |  232 ++
 drivers/soundwire/mipi_disco.c |  422 ++
 drivers/soundwire/slave.c  |  173 
 drivers/soundwire/sysfs.c  |  388 +
 include/linux/mod_devicetable.h|6 +
 include/linux/regmap.h |   37 +
 include/linux/soundwire/sdw.h  |  563 +
 include/linux/soundwire/sdw_intel.h|   74 ++
 include/linux/soundwire/sdw_registers.h|  242 ++
 scripts/mod/devicetable-offsets.c  |4 +
 scripts/mod/file2alias.c   |   15 +
 28 files changed, 5313 insertions(+)
 create mode 100644 Documentation/driver-api/soundwire/index.rst
 create mode 100644 Documentation/driver-api/soundwire/summary.rst
 create mode 100644 drivers/base/regmap/regmap-sdw.c
 create mode 100644 drivers/soundwire/Kconfig
 create mode 100644 drivers/soundwire/Makefile
 create mode 100644 drivers/soundwire/bus.c
 create mode 100644 drivers/soundwire/bus.h
 create mode 100644 drivers/soundwire/bus_type.c
 create mode 100644 drivers/soundwire/cadence_master.c
 create mode 100644 drivers/soundwire/cadence_master.h
 create mode 100644 drivers/soundwire/intel.c
 create mode 100644 drivers/soundwire/intel.h
 create mode 100644 drivers/soundwire/intel_init.c
 create mode 100644 drivers/soundwire/mipi_disco.c
 create mode 100644 drivers/soundwire/slave.c
 create mode 100644 drivers/soundwire/sysfs.c
 create mode 100644 include/linux/soundwire/sdw.h
 create mode 100644 include/linux/soundwire/sdw_intel.h
 create mode 100644 include/linux/soundwire/sdw_registers.h

-- 
2.7.4

[PATCH v2 07/14] regmap: Add SoundWire bus support

[Vinod Koul]

SoundWire bus provides sdw_read() and sdw_write() APIs for Slave
devices to program the registers. Provide support in regmap for
SoundWire bus.

Signed-off-by: Hardik T Shah 
Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/base/regmap/Kconfig  |   4 ++
 drivers/base/regmap/Makefile |   1 +
 drivers/base/regmap/regmap-sdw.c | 140 +++
 drivers/soundwire/Kconfig|   1 +
 include/linux/regmap.h   |  37 +++
 5 files changed, 183 insertions(+)
 create mode 100644 drivers/base/regmap/regmap-sdw.c

diff --git a/drivers/base/regmap/Kconfig b/drivers/base/regmap/Kconfig
index 073c0b77e5b3..d0310fbaa8e7 100644
--- a/drivers/base/regmap/Kconfig
+++ b/drivers/base/regmap/Kconfig
@@ -36,3 +36,7 @@ config REGMAP_MMIO
 
 config REGMAP_IRQ
bool
+
+config REGMAP_SOUNDWIRE
+   tristate
+   depends on SOUNDWIRE_BUS
diff --git a/drivers/base/regmap/Makefile b/drivers/base/regmap/Makefile
index 0cf4abc8fbf1..13004c979881 100644
--- a/drivers/base/regmap/Makefile
+++ b/drivers/base/regmap/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_REGMAP_SPMI) += regmap-spmi.o
 obj-$(CONFIG_REGMAP_MMIO) += regmap-mmio.o
 obj-$(CONFIG_REGMAP_IRQ) += regmap-irq.o
 obj-$(CONFIG_REGMAP_W1) += regmap-w1.o
+obj-$(CONFIG_REGMAP_SOUNDWIRE) += regmap-sdw.o
diff --git a/drivers/base/regmap/regmap-sdw.c b/drivers/base/regmap/regmap-sdw.c
new file mode 100644
index ..327b916b0e36
--- /dev/null
+++ b/drivers/base/regmap/regmap-sdw.c
@@ -0,0 +1,140 @@
+/*
+ *  This file is provided under a dual BSD/GPLv2 license.  When using or
+ *  redistributing this file, you may do so under either license.
+ *
+ *  SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+ *
+ *  GPL LICENSE SUMMARY
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of version 2 of the GNU General Public License as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Intel Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "internal.h"
+
+static int regmap_sdw_write(void *context, unsigned int reg, unsigned int val)
+{
+   struct device *dev = context;
+   struct sdw_slave *slave = dev_to_sdw_dev(dev);
+
+   return sdw_write(slave, reg, val);
+}
+
+static int regmap_sdw_read(void *context, unsigned int reg, unsigned int *val)
+{
+   struct device *dev = context;
+   struct sdw_slave *slave = dev_to_sdw_dev(dev);
+   int read;
+
+   read = sdw_read(slave, reg);
+   if (read < 0)
+   return read;
+
+   *val = read;
+   return 0;
+}
+
+static struct regmap_bus regmap_sdw = {
+   .reg_read = regmap_sdw_read,
+   .reg_write = regmap_sdw_write,
+   .reg_format_endian_default = REGMAP_ENDIAN_LITTLE,
+   .val_format_endian_default = REGMAP_ENDIAN_LITTLE,
+};
+
+static int regmap_sdw_config_check(const struct regmap_config *config)
+{
+   /* All register are 8-bits wide as per MIPI 

[PATCH v2 08/14] soundwire: Add Slave status handling helpers

[Vinod Koul]

From: Sanyog Kale 

SoundWire Slaves report status to bus. Add helpers to handle
the status changes.

Signed-off-by: Hardik T Shah 
Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/bus.c   | 213 ++
 include/linux/soundwire/sdw.h |   1 +
 2 files changed, 214 insertions(+)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 70b60ba84592..16bc295634de 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -419,6 +419,93 @@ int sdw_write(struct sdw_slave *slave, u32 addr, u8 value)
 }
 EXPORT_SYMBOL(sdw_write);
 
+/*
+ * SDW alert handling
+ */
+
+/* called with bus_lock held */
+static struct sdw_slave *sdw_get_slave(struct sdw_bus *bus, int i)
+{
+   struct sdw_slave *slave = NULL;
+
+   list_for_each_entry(slave, >slaves, node) {
+   if (slave->dev_num == i)
+   break;
+   }
+
+   return slave;
+}
+
+static int sdw_compare_devid(struct sdw_slave *slave, struct sdw_slave_id id)
+{
+
+   if ((slave->id.unique_id != id.unique_id) ||
+   (slave->id.mfg_id != id.mfg_id) ||
+   (slave->id.part_id != id.part_id) ||
+   (slave->id.class_id != id.class_id))
+   return -ENODEV;
+
+   return 0;
+}
+
+/* called with bus_lock held */
+static int sdw_get_device_num(struct sdw_slave *slave)
+{
+   int bit;
+
+   bit = find_first_zero_bit(slave->bus->assigned, SDW_MAX_DEVICES);
+   if (bit == SDW_MAX_DEVICES) {
+   bit = -ENODEV;
+   goto err;
+   }
+
+   /*
+* Do not update dev_num in Slave data structure here,
+* Update once program dev_num is successful
+*/
+   set_bit(bit, slave->bus->assigned);
+
+err:
+   return bit;
+}
+
+static int sdw_assign_device_num(struct sdw_slave *slave)
+{
+   int ret, dev_num;
+
+   /* check first if device number is assigned, if so reuse that */
+   if (!slave->dev_num) {
+   mutex_lock(>bus->bus_lock);
+   dev_num = sdw_get_device_num(slave);
+   mutex_unlock(>bus->bus_lock);
+   if (dev_num < 0) {
+   dev_err(slave->bus->dev, "Get dev_num failed: %d",
+   dev_num);
+   return dev_num;
+   }
+   } else {
+   dev_info(slave->bus->dev,
+   "Slave already registered dev_num:%d",
+   slave->dev_num);
+
+   /* Clear the slave->dev_num to transfer message on device 0 */
+   dev_num = slave->dev_num;
+   slave->dev_num = 0;
+
+   }
+
+   ret = sdw_write(slave, SDW_SCP_DEVNUMBER, dev_num);
+   if (ret < 0) {
+   dev_err(>dev, "Program device_num failed: %d", ret);
+   return ret;
+   }
+
+   /* After xfer of msg, restore dev_num */
+   slave->dev_num = dev_num;
+
+   return 0;
+}
+
 void sdw_extract_slave_id(struct sdw_bus *bus,
u64 addr, struct sdw_slave_id *id)
 {
@@ -447,3 +534,129 @@ void sdw_extract_slave_id(struct sdw_bus *bus,
id->unique_id, id->sdw_version);
 
 }
+
+static int sdw_program_device_num(struct sdw_bus *bus)
+{
+   u8 buf[SDW_NUM_DEV_ID_REGISTERS] = {0};
+   struct sdw_slave *slave, *_s;
+   struct sdw_slave_id id;
+   struct sdw_msg msg;
+   bool found = false;
+   int count = 0, ret;
+   u64 addr;
+
+   /* No Slave, so use raw xfer api */
+   ret = sdw_fill_msg(, NULL, SDW_SCP_DEVID_0, 
SDW_NUM_DEV_ID_REGISTERS,
+   0, SDW_MSG_FLAG_READ, buf);
+   if (ret < 0)
+   return ret;
+
+   do {
+   ret = sdw_transfer(bus, NULL, );
+   if (ret == -ENODATA)
+   break;
+   if (ret < 0) {
+   dev_err(bus->dev, "DEVID read fail:%d\n", ret);
+   break;
+   }
+
+   /*
+* Construct the addr and extract. Cast the higher shift
+* bits to avoid truncation due to size limit.
+*/
+   addr = buf[5] | (buf[4] << 8) | (buf[3] << 16) |
+   (buf[2] << 24) | ((unsigned long long)buf[1] << 32) |
+   ((unsigned long long)buf[0] << 40);
+
+   sdw_extract_slave_id(bus, addr, );
+
+   /* Now compare with entries */
+   list_for_each_entry_safe(slave, _s, >slaves, node) {
+   if (sdw_compare_devid(slave, id) == 0) {
+   found = true;
+
+   /*
+* Assign a new dev_num to this Slave and
+ 

[PATCH v2 3/3] HID: cp2112: fix broken gpio_direction_input callback

[Sébastien Szymanski]

When everything goes smoothly, ret is set to 0 which makes the function
to return EIO error.

Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
Signed-off-by: Sébastien Szymanski 
---
Changes in v2:
 - rework error handling to have only one exit path as suggested by
   Benjamin Tissoires 

 drivers/hid/hid-cp2112.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
index 28e3c18..68cdc96 100644
--- a/drivers/hid/hid-cp2112.c
+++ b/drivers/hid/hid-cp2112.c
@@ -196,6 +196,8 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
*chip, unsigned offset)
 HID_REQ_GET_REPORT);
if (ret != CP2112_GPIO_CONFIG_LENGTH) {
hid_err(hdev, "error requesting GPIO config: %d\n", ret);
+   if (ret >= 0)
+   ret = -EIO;
goto exit;
}
 
@@ -205,8 +207,10 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
*chip, unsigned offset)
ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf,
 CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT,
 HID_REQ_SET_REPORT);
-   if (ret < 0) {
+   if (ret != CP2112_GPIO_CONFIG_LENGTH) {
hid_err(hdev, "error setting GPIO config: %d\n", ret);
+   if (ret >= 0)
+   ret = -EIO;
goto exit;
}
 
@@ -214,7 +218,7 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
*chip, unsigned offset)
 
 exit:
mutex_unlock(>lock);
-   return ret < 0 ? ret : -EIO;
+   return ret;
 }
 
 static void cp2112_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
-- 
2.7.3

Re: [PATCH 18/30] x86, kaiser: map virtually-addressed performance monitoring buffers

[Peter Zijlstra]

On Wed, Nov 08, 2017 at 11:47:20AM -0800, Dave Hansen wrote:
> +static
> +DEFINE_PER_CPU_SHARED_ALIGNED_USER_MAPPED(struct debug_store, 
> cpu_debug_store);
> +
>  /* The size of a BTS record in bytes: */
>  #define BTS_RECORD_SIZE  24
>  
> @@ -278,6 +282,39 @@ void fini_debug_store_on_cpu(int cpu)
>  
>  static DEFINE_PER_CPU(void *, insn_buffer);
>  
> +static void *dsalloc(size_t size, gfp_t flags, int node)
> +{
> +#ifdef CONFIG_KAISER
> + unsigned int order = get_order(size);
> + struct page *page;
> + unsigned long addr;
> +
> + page = __alloc_pages_node(node, flags | __GFP_ZERO, order);
> + if (!page)
> + return NULL;
> + addr = (unsigned long)page_address(page);
> + if (kaiser_add_mapping(addr, size, __PAGE_KERNEL | _PAGE_GLOBAL) < 0) {
> + __free_pages(page, order);
> + addr = 0;
> + }
> + return (void *)addr;
> +#else
> + return kmalloc_node(size, flags | __GFP_ZERO, node);
> +#endif
> +}
> +
> +static void dsfree(const void *buffer, size_t size)
> +{
> +#ifdef CONFIG_KAISER
> + if (!buffer)
> + return;
> + kaiser_remove_mapping((unsigned long)buffer, size);
> + free_pages((unsigned long)buffer, get_order(size));
> +#else
> + kfree(buffer);
> +#endif
> +}

You might as well use __alloc_pages_node() / free_pages()
unconditionally. Those buffers are at least one page in size.

That should also get rid of the #ifdef muck.

>  static int alloc_ds_buffer(int cpu)
>  {
> - int node = cpu_to_node(cpu);
> - struct debug_store *ds;
> -
> - ds = kzalloc_node(sizeof(*ds), GFP_KERNEL, node);
> - if (unlikely(!ds))
> - return -ENOMEM;
> + struct debug_store *ds = per_cpu_ptr(_debug_store, cpu);
>  
> + memset(ds, 0, sizeof(*ds));

Why the memset() ? isn't static per-cpu memory 0 initialized

Re: [PATCH v2 3/3] HID: cp2112: fix broken gpio_direction_input callback

[Jiri Kosina]

On Fri, 10 Nov 2017, Sébastien Szymanski wrote:

> When everything goes smoothly, ret is set to 0 which makes the function
> to return EIO error.
> 
> Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling")
> Signed-off-by: Sébastien Szymanski 
> ---
> Changes in v2:
>  - rework error handling to have only one exit path as suggested by
>Benjamin Tissoires 

Applied to for-4.15/upstream.

-- 
Jiri Kosina
SUSE Labs

[PATCH 3/4] ASN.1: Improve exiting from build_type_list()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 10 Nov 2017 12:56:33 +0100

* Add jump targets so that a call of the function "perror" and "exit"
  is stored only once in an if branch of this function.

* Replace two calls by goto statements.

Signed-off-by: Markus Elfring 
---
 scripts/asn1_compiler.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/scripts/asn1_compiler.c b/scripts/asn1_compiler.c
index 0eea270fcaef..06dc5397d8c8 100644
--- a/scripts/asn1_compiler.c
+++ b/scripts/asn1_compiler.c
@@ -762,18 +762,19 @@ static void build_type_list(void)
 
if (nr == 0) {
fprintf(stderr, "%s: No defined types\n", filename);
-   exit(1);
+   goto exit;
}
 
nr_types = nr;
types = type_list = calloc(nr + 1, sizeof(type_list[0]));
-   if (!type_list) {
-   perror(NULL);
-   exit(1);
-   }
+   if (!type_list)
+   goto report_failure;
+
type_index = calloc(nr, sizeof(type_index[0]));
if (!type_index) {
+report_failure:
perror(NULL);
+exit:
exit(1);
}
 
-- 
2.15.0

Re: [PATCH v5 09/26] KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain

[Christoffer Dall]

On Tue, Nov 07, 2017 at 02:08:23PM +0100, Auger Eric wrote:
> Hi Marc,
> 
> On 27/10/2017 16:28, Marc Zyngier wrote:
> > In order to control the GICv4 view of virtual CPUs, we rely
> > on an irqdomain allocated for that purpose. Let's add a couple
> > of helpers to that effect.
> > 
> > At the same time, the vgic data structures gain new fields to
> > track all this... erm... wonderful stuff.
> > 
> > The way we hook into the vgic init is slightly convoluted. We
> > need the vgic to be initialized (in order to guarantee that
> > the number of vcpus is now fixed), and we must have a vITS
> > (otherwise this is all very pointless). So we end-up calling
> > the init from both vgic_init and vgic_its_create.
> > 
> > Reviewed-by: Christoffer Dall 
> > Signed-off-by: Marc Zyngier 
> > ---
> >  arch/arm/kvm/Makefile |  1 +
> >  arch/arm64/kvm/Makefile   |  1 +
> >  include/kvm/arm_vgic.h| 19 ++
> >  virt/kvm/arm/vgic/vgic-init.c |  9 +
> >  virt/kvm/arm/vgic/vgic-its.c  |  8 +
> >  virt/kvm/arm/vgic/vgic-v4.c   | 83 
> > +++
> >  virt/kvm/arm/vgic/vgic.h  |  2 ++
> >  7 files changed, 123 insertions(+)
> >  create mode 100644 virt/kvm/arm/vgic/vgic-v4.c
> > 
> > diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
> > index d9beee652d36..0a1dd2cdb928 100644
> > --- a/arch/arm/kvm/Makefile
> > +++ b/arch/arm/kvm/Makefile
> > @@ -31,6 +31,7 @@ obj-y += $(KVM)/arm/vgic/vgic-init.o
> >  obj-y += $(KVM)/arm/vgic/vgic-irqfd.o
> >  obj-y += $(KVM)/arm/vgic/vgic-v2.o
> >  obj-y += $(KVM)/arm/vgic/vgic-v3.o
> > +obj-y += $(KVM)/arm/vgic/vgic-v4.o
> >  obj-y += $(KVM)/arm/vgic/vgic-mmio.o
> >  obj-y += $(KVM)/arm/vgic/vgic-mmio-v2.o
> >  obj-y += $(KVM)/arm/vgic/vgic-mmio-v3.o
> > diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> > index 5d9810086c25..c30fd388ef80 100644
> > --- a/arch/arm64/kvm/Makefile
> > +++ b/arch/arm64/kvm/Makefile
> > @@ -26,6 +26,7 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-init.o
> >  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-irqfd.o
> >  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-v2.o
> >  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-v3.o
> > +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-v4.o
> >  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio.o
> >  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v2.o
> >  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
> > diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> > index ba9fb450aa1b..7eeb6c2a2f9c 100644
> > --- a/include/kvm/arm_vgic.h
> > +++ b/include/kvm/arm_vgic.h
> > @@ -26,6 +26,8 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +
> >  #define VGIC_V3_MAX_CPUS   255
> >  #define VGIC_V2_MAX_CPUS   8
> >  #define VGIC_NR_IRQS_LEGACY 256
> > @@ -236,6 +238,15 @@ struct vgic_dist {
> >  
> > /* used by vgic-debug */
> > struct vgic_state_iter *iter;
> > +
> > +   /*
> > +* GICv4 ITS per-VM data, containing the IRQ domain, the VPE
> > +* array, the property table pointer as well as allocation
> > +* data. This essentially ties the Linux IRQ core and ITS
> > +* together, and avoids leaking KVM's data structures anywhere
> > +* else.
> > +*/
> > +   struct its_vm   its_vm;
> >  };
> >  
> >  struct vgic_v2_cpu_if {
> > @@ -254,6 +265,14 @@ struct vgic_v3_cpu_if {
> > u32 vgic_ap0r[4];
> > u32 vgic_ap1r[4];
> > u64 vgic_lr[VGIC_V3_MAX_LRS];
> > +
> > +   /*
> > +* GICv4 ITS per-VPE data, containing the doorbell IRQ, the
> > +* pending table pointer, the its_vm pointer and a few other
> > +* HW specific things. As for the its_vm structure, this is
> > +* linking the Linux IRQ subsystem and the ITS together.
> > +*/
> > +   struct its_vpe  its_vpe;
> >  };
> >  
> >  struct vgic_cpu {
> > diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
> > index 5801261f3add..40be908da238 100644
> > --- a/virt/kvm/arm/vgic/vgic-init.c
> > +++ b/virt/kvm/arm/vgic/vgic-init.c
> > @@ -285,6 +285,12 @@ int vgic_init(struct kvm *kvm)
> > if (ret)
> > goto out;
> >  
> > +   if (vgic_supports_direct_msis(kvm)) {
> > +   ret = vgic_v4_init(kvm);
> > +   if (ret)
> > +   goto out;
> > +   }
> > +
> > kvm_for_each_vcpu(i, vcpu, kvm)
> > kvm_vgic_vcpu_enable(vcpu);
> >  
> > @@ -320,6 +326,9 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
> >  
> > kfree(dist->spis);
> > dist->nr_spis = 0;
> > +
> > +   if (vgic_supports_direct_msis(kvm))
> > +   vgic_v4_teardown(kvm);
> >  }
> >  
> >  void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
> > diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> > index 8ee03f1e89fc..89768d2b6a91 100644
> > --- a/virt/kvm/arm/vgic/vgic-its.c
> > +++ 

Re: [PATCH v5 16/26] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs

[Christoffer Dall]

On Wed, Nov 08, 2017 at 03:08:36PM +, Marc Zyngier wrote:
> On 07/11/17 21:28, Auger Eric wrote:
> > Hi Marc,
> > 
> > On 27/10/2017 16:28, Marc Zyngier wrote:
> >> Upon updating a property, we propagate it all the way to the physical
> >> ITS, and ask for an INV command to be executed there.
> >>
> >> Acked-by: Christoffer Dall 
> >> Signed-off-by: Marc Zyngier 
> >> ---
> >>  virt/kvm/arm/vgic/vgic-its.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> >> index 0b7e648e7a0c..2e77c7c83942 100644
> >> --- a/virt/kvm/arm/vgic/vgic-its.c
> >> +++ b/virt/kvm/arm/vgic/vgic-its.c
> >> @@ -296,6 +296,9 @@ static int update_lpi_config(struct kvm *kvm, struct 
> >> vgic_irq *irq,
> >>spin_unlock(>irq_lock);
> >>}
> >>  
> >> +  if (irq->hw)
> >> +  return its_prop_update_vlpi(irq->host_irq, prop, true);
> >> +
> >>return 0;
> >>  }
> > I am confused by the vgic_queue_irq_unlock() on the "hw" path. Why is it
> > needed in hw mode?
> 
> It's not. I guess we could bypass this altogether and take a short cut
> after having updated the priority and enabled fields.
> 

I can apply this on top of the series as well if you're happy with it:

commit b54fba93b1330803a59ca75f3a5102e22cadc871 (HEAD -> next-gicv4)
Author: Christoffer Dall 
Date:   Fri Nov 10 09:34:54 2017 +0100

KVM: arm/arm64: Don't queue VLPIs on INV/INVALL

Since VLPIs are injected directly by the hardware there's no need to
mark these as pending in software and queue them on the AP list.

Signed-off-by: Christoffer Dall 

diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index c93ecd4a903b..a3754ec719c4 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -292,11 +292,14 @@ static int update_lpi_config(struct kvm *kvm, struct 
vgic_irq *irq,
irq->priority = LPI_PROP_PRIORITY(prop);
irq->enabled = LPI_PROP_ENABLE_BIT(prop);
 
-   vgic_queue_irq_unlock(kvm, irq, flags);
-   } else {
-   spin_unlock_irqrestore(>irq_lock, flags);
+   if (!irq->hw) {
+   vgic_queue_irq_unlock(kvm, irq, flags);
+   return 0;
+   }
}
 
+   spin_unlock_irqrestore(>irq_lock, flags);
+
if (irq->hw)
return its_prop_update_vlpi(irq->host_irq, prop, needs_inv);
 


Thanks,
-Christoffer

[PATCH] perf parse events: Fix invalid precise_ip handling

[Mengting Zhang]

When the user set a precise_ip greater than the highest precision available,
perf should return EINVAL to indicate the invalid precise_ip setting.

Currently, in get_event_modifier(), perf compares the user-specified precise_ip
with 3, instead of the highest precision available in the current processor.
It is incorrect if the maximum precision available is less than 3.

For example, with a highest precision perf_event_attr.precise_ip = 2, the
user-specified precise_ip greater than 2 should be handled as invalid argument.

Introduce perf_get_max_precise_ip() to get max precision available and compare
it with the user-specified precise_ip. Also show the available max precision in
an error message when the user-specified precise_ip is invalid.

Before:
$./perf record -e cycles:ppp sleep 1
Error:
PMU Hardware doesn't support sampling/overflow-interrupts.

After:
$./perf record -e cycles:ppp sleep 1
Error: Invalid argument for precise_ip setting.
The highest level of precise ip is 2
invalid or unsupported event: 'cycles:ppp'
Run 'perf list' for a list of valid events

 Usage: perf record [] []
or: perf record [] --  []

-e, --eventevent selector. use 'perf list' to list available 
events

Signed-off-by: Mengting Zhang 
---
 tools/perf/util/parse-events.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 39b1596..25225f4 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1369,6 +1369,32 @@ struct event_modifier {
int pinned;
 };
 
+static int perf_get_max_precise_ip(void)
+{
+   int max_precise_ip = 0;
+   struct perf_event_attr attr = {
+   .type   = PERF_TYPE_HARDWARE,
+   .config = PERF_COUNT_HW_CPU_CYCLES,
+   };
+
+   event_attr_init();
+   
+   attr.precise_ip = 3;
+   attr.sample_period = 1;
+
+   while (attr.precise_ip != 0) {
+   int fd = sys_perf_event_open(, 0, -1, -1, 0);
+   if (fd != -1){
+   close(fd);
+   break;
+   }
+   --attr.precise_ip;
+   }
+   max_precise_ip = attr.precise_ip;
+
+   return max_precise_ip;
+}
+
 static int get_event_modifier(struct event_modifier *mod, char *str,
   struct perf_evsel *evsel)
 {
@@ -1382,6 +1408,7 @@ static int get_event_modifier(struct event_modifier *mod, 
char *str,
int precise_max = 0;
int sample_read = 0;
int pinned = evsel ? evsel->attr.pinned : 0;
+   int max_precise_ip = 0;
 
int exclude = eu | ek | eh;
int exclude_GH = evsel ? evsel->exclude_GH : 0;
@@ -1438,8 +1465,12 @@ static int get_event_modifier(struct event_modifier 
*mod, char *str,
 *
 *  See also PERF_RECORD_MISC_EXACT_IP
 */
-   if (precise > 3)
+   max_precise_ip = perf_get_max_precise_ip();
+   if (precise > max_precise_ip) {
+   pr_err("Error: Invalid argument for precise_ip setting. \n"
+   "The highest level of precise ip is %d\n", 
max_precise_ip);
return -EINVAL;
+   }
 
mod->eu = eu;
mod->ek = ek;
-- 
1.7.12.4

Re: [PATCH 3/4] kbuild: create object directories simpler and faster

[Cao jin]

Hi Masahiro-san,

On 11/09/2017 11:41 PM, Masahiro Yamada wrote:
> For the out-of-tree build, scripts/Makefile.build creates output
> directories, but this operation is not efficient.
> 
> scripts/Makefile.lib calculates obj-dirs as follows:
> 
>   obj-dirs := $(dir $(multi-objs) $(obj-y))
> 
> Please notice $(sort ...) is not used here.  Usually the resulted
> obj-dirs is as many "./" as objects.
> 
> For those duplicated paths, the following command is invoked.
> 
>   _dummy := $(foreach d,$(obj-dirs), $(shell [ -d $(d) ] || mkdir -p $(d)))
> 
> Then, the costly shell command is run over and over again.
> 
> I see many points for optimization:
> 
> [1] Use $(sort ...) to cut down duplicated paths before passing them
> to system call
> [2] Use single $(shell ...) instead of repeating it with $(foreach ...)
> This will reduce forking.
> [3] We can calculate obj-dirs more simply.  Most of objects are already
> accumulated in $(targets).  So, $(dir $(targets)) is fine and more
> comprehensive.
> 
> I also removed bad code in arch/x86/entry/vdso/Makefile.  This is now
> really unnecessary.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/x86/entry/vdso/Makefile |  4 
>  scripts/Makefile.build   | 15 ++-
>  scripts/Makefile.host| 11 ---
>  scripts/Makefile.lib |  5 -
>  4 files changed, 6 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index d540966..f8e3d85 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -129,10 +129,6 @@ $(obj)/vdsox32.so.dbg: $(src)/vdsox32.lds $(vobjx32s) 
> FORCE
>  CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
>  VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-m,elf_i386 -Wl,-soname=linux-gate.so.1
>  
> -# This makes sure the $(obj) subdirectory exists even though vdso32/
> -# is not a kbuild sub-make subdirectory.
> -override obj-dirs = $(dir $(obj)) $(obj)/vdso32/
> -
>  targets += vdso32/vdso32.lds
>  targets += vdso32/note.o vdso32/system_call.o vdso32/sigreturn.o
>  targets += vdso32/vclock_gettime.o
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 62d5314..89ac180 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -64,15 +64,6 @@ ifneq 
> ($(hostprogs-y)$(hostprogs-m)$(hostlibs-y)$(hostlibs-m)$(hostcxxlibs-y)$(h
>  include scripts/Makefile.host
>  endif
>  
> -ifneq ($(KBUILD_SRC),)
> -# Create output directory if not already present
> -_dummy := $(shell [ -d $(obj) ] || mkdir -p $(obj))
> -
> -# Create directories for object files if directory does not exist
> -# Needed when obj-y := dir/file.o syntax is used
> -_dummy := $(foreach d,$(obj-dirs), $(shell [ -d $(d) ] || mkdir -p $(d)))
> -endif
> -
>  ifndef obj
>  $(warning kbuild: Makefile.build is included improperly)
>  endif
> @@ -589,6 +580,12 @@ ifneq ($(cmd_files),)
>include $(cmd_files)
>  endif
>  
> +ifneq ($(KBUILD_SRC),)
> +# Create directories for object files if directory does not exist
> +obj-dirs := $(sort $(obj) $(patsubst %/,%, $(dir $(targets
> +$(shell mkdir -p $(obj-dirs))
> +endif
> +

I just take a quick glance: is "$(obj)" here necessary? I think all
$(targets) are under directory $(obj) when we descend into $(obj) to
recursive make, if I don't miss anything.

-- 
Sincerely,
Cao jin

>  # Declare the contents of the .PHONY variable as phony.  We keep that
>  # information in a variable se we can use it in if_changed and friends.
>  
> diff --git a/scripts/Makefile.host b/scripts/Makefile.host
> index 9cfd5c8..3a5460d 100644
> --- a/scripts/Makefile.host
> +++ b/scripts/Makefile.host
> @@ -48,15 +48,6 @@ host-cxxobjs   := $(sort $(foreach 
> m,$(host-cxxmulti),$($(m)-cxxobjs)))
>  host-cshobjs := $(sort $(foreach m,$(host-cshlib),$($(m:.so=-objs
>  host-cxxshobjs   := $(sort $(foreach 
> m,$(host-cxxshlib),$($(m:.so=-objs
>  
> -# output directory for programs/.o files
> -# hostprogs-y := tools/build may have been specified.
> -# Retrieve also directory of .o files from prog-objs or prog-cxxobjs notation
> -host-objdirs := $(dir $(__hostprogs) $(host-cobjs) $(host-cxxobjs))
> -
> -host-objdirs := $(strip $(sort $(filter-out ./,$(host-objdirs
> -
> -
> -__hostprogs := $(addprefix $(obj)/,$(__hostprogs))
>  host-csingle := $(addprefix $(obj)/,$(host-csingle))
>  host-cmulti  := $(addprefix $(obj)/,$(host-cmulti))
>  host-cobjs   := $(addprefix $(obj)/,$(host-cobjs))
> @@ -68,8 +59,6 @@ host-cshobjs:= $(addprefix $(obj)/,$(host-cshobjs))
>  host-cxxshobjs   := $(addprefix $(obj)/,$(host-cxxshobjs))
>  host-objdirs:= $(addprefix $(obj)/,$(host-objdirs))
>  
> -obj-dirs += $(host-objdirs)
> -
>  #
>  # Handle options to gcc. Support building with separate output directory
>  
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 4d88ad7..5fbc46d 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -50,15 

Re: [PATCH v5 17/26] KVM: arm/arm64: GICv4: Handle INVALL applied to a vPE

[Marc Zyngier]

On 10/11/17 08:41, Christoffer Dall wrote:
> On Tue, Nov 07, 2017 at 10:23:25PM +0100, Auger Eric wrote:
>> Hi Marc,
>>
>> On 27/10/2017 16:28, Marc Zyngier wrote:
>>> Since when updating the properties one LPI at a time, there is no
>> Since we update the properties one LPI at a time, ... ?
>>> need to perform an INV each time we read one. Instead, we rely
>>> on the final VINVALL that gets sent to the ITS to do the work.
>> The commit message is not crystal clear for me.
>>
>> I understand in case of vgic_its_cmd_handle_invall you want to avoid
>> doing an invalidation for each physical irq but rather do an
>> its_invall_vpe at the end. So you add a new  @needs_inv arg to
>> update_lpi_config to tell whether the invalidation should be done or not.
> 
> I've reworded it to:
> 
>   There is no need to perform an INV for each interrupt when updating
>   multiple interrupts.  Instead, we can rely on the final VINVALL that
>   gets sent to the ITS to do the work for all of them.
> 
> 
> Shout quickly if you have any objections.

Works for me.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 3/4] kbuild: create object directories simpler and faster

[Masahiro Yamada]

Hi Cao,


2017-11-10 17:45 GMT+09:00 Cao jin :

>> +ifneq ($(KBUILD_SRC),)
>> +# Create directories for object files if directory does not exist
>> +obj-dirs := $(sort $(obj) $(patsubst %/,%, $(dir $(targets
>> +$(shell mkdir -p $(obj-dirs))
>> +endif
>> +
>
> I just take a quick glance: is "$(obj)" here necessary? I think all
> $(targets) are under directory $(obj) when we descend into $(obj) to
> recursive make, if I don't miss anything.

Good catch!

I agree that $(obj) is unnecessary.
I will remove it if I see no problem in testing.

Thanks!


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 0/2][v5] Add the ability to do BPF directed error injection

[Peter Zijlstra]

On Wed, Nov 08, 2017 at 06:43:25AM +0900, Alexei Starovoitov wrote:
> On 11/8/17 5:28 AM, Josef Bacik wrote:
> > I'm sending this through Dave since it'll conflict with other BPF changes 
> > in his
> > tree, but since it touches tracing as well Dave would like a review from
> > somebody on the tracing side.
> > 
> > v4->v5:
> > - disallow kprobe_override programs from being put in the prog map array so 
> > we
> >   don't tail call into something we didn't check.  This allows us to make 
> > the
> >   normal path still fast without a bunch of percpu operations.
> 
> looks great to me.
> Peter,
> could you please review x86 bits?

I did not in fact get the patch... But after digging it out of LKML I
don't immediately see something broken, but this is not stuff I
typically know well.

Re: [PATCH 1/2] bpf: add a bpf_override_function helper

[Ingo Molnar]

* Josef Bacik  wrote:

> @@ -551,6 +578,10 @@ static const struct bpf_func_proto 
> *kprobe_prog_func_proto(enum bpf_func_id func
>   return _get_stackid_proto;
>   case BPF_FUNC_perf_event_read_value:
>   return _perf_event_read_value_proto;
> + case BPF_FUNC_override_return:
> + pr_warn_ratelimited("%s[%d] is installing a program with 
> bpf_override_return helper that may cause unexpected behavior!",
> + current->comm, task_pid_nr(current));
> + return _override_return_proto;

So if this new functionality is used we'll always print this into the syslog?

The warning is also a bit passive aggressive about informing the user: what 
unexpected behavior can happen, what is the worst case?

Thanks,

Ingo

[tip:x86/platform] x86/virt: Add enum for hypervisors to replace x86_hyper

[tip-bot for Juergen Gross]

Commit-ID:  03b2a320b19f1424e9ac9c21696be9c60b6d0d93
Gitweb: https://git.kernel.org/tip/03b2a320b19f1424e9ac9c21696be9c60b6d0d93
Author: Juergen Gross 
AuthorDate: Thu, 9 Nov 2017 14:27:36 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 10 Nov 2017 10:03:12 +0100

x86/virt: Add enum for hypervisors to replace x86_hyper

The x86_hyper pointer is only used for checking whether a virtual
device is supporting the hypervisor the system is running on.

Use an enum for that purpose instead and drop the x86_hyper pointer.

Signed-off-by: Juergen Gross 
Acked-by: Thomas Gleixner 
Acked-by: Xavier Deguillard 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: akata...@vmware.com
Cc: a...@arndb.de
Cc: boris.ostrov...@oracle.com
Cc: de...@linuxdriverproject.org
Cc: dmitry.torok...@gmail.com
Cc: gre...@linuxfoundation.org
Cc: haiya...@microsoft.com
Cc: k...@vger.kernel.org
Cc: k...@microsoft.com
Cc: linux-graphics-maintai...@vmware.com
Cc: linux-in...@vger.kernel.org
Cc: moltm...@vmware.com
Cc: pbonz...@redhat.com
Cc: pv-driv...@vmware.com
Cc: rkrc...@redhat.com
Cc: sthem...@microsoft.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
Link: http://lkml.kernel.org/r/20171109132739.23465-3-jgr...@suse.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/hyperv/hv_init.c |  2 +-
 arch/x86/include/asm/hypervisor.h | 23 ++-
 arch/x86/kernel/cpu/hypervisor.c  | 12 +---
 arch/x86/kernel/cpu/mshyperv.c|  4 ++--
 arch/x86/kernel/cpu/vmware.c  |  4 ++--
 arch/x86/kernel/kvm.c |  4 ++--
 arch/x86/xen/enlighten_hvm.c  |  4 ++--
 arch/x86/xen/enlighten_pv.c   |  4 ++--
 drivers/hv/vmbus_drv.c|  2 +-
 drivers/input/mouse/vmmouse.c | 10 --
 drivers/misc/vmw_balloon.c|  2 +-
 11 files changed, 40 insertions(+), 31 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index a5db63f..a0b86cf 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -113,7 +113,7 @@ void hyperv_init(void)
u64 guest_id;
union hv_x64_msr_hypercall_contents hypercall_msr;
 
-   if (x86_hyper != _hyper_ms_hyperv)
+   if (x86_hyper_type != X86_HYPER_MS_HYPERV)
return;
 
/* Allocate percpu VP index */
diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 0eca723..1b0a5abc 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -29,6 +29,16 @@
 /*
  * x86 hypervisor information
  */
+
+enum x86_hypervisor_type {
+   X86_HYPER_NATIVE = 0,
+   X86_HYPER_VMWARE,
+   X86_HYPER_MS_HYPERV,
+   X86_HYPER_XEN_PV,
+   X86_HYPER_XEN_HVM,
+   X86_HYPER_KVM,
+};
+
 struct hypervisor_x86 {
/* Hypervisor name */
const char  *name;
@@ -36,6 +46,9 @@ struct hypervisor_x86 {
/* Detection routine */
uint32_t(*detect)(void);
 
+   /* Hypervisor type */
+   enum x86_hypervisor_type type;
+
/* init time callbacks */
struct x86_hyper_init init;
 
@@ -43,15 +56,7 @@ struct hypervisor_x86 {
struct x86_hyper_runtime runtime;
 };
 
-extern const struct hypervisor_x86 *x86_hyper;
-
-/* Recognized hypervisors */
-extern const struct hypervisor_x86 x86_hyper_vmware;
-extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
-extern const struct hypervisor_x86 x86_hyper_xen_pv;
-extern const struct hypervisor_x86 x86_hyper_xen_hvm;
-extern const struct hypervisor_x86 x86_hyper_kvm;
-
+extern enum x86_hypervisor_type x86_hyper_type;
 extern void init_hypervisor_platform(void);
 #else
 static inline void init_hypervisor_platform(void) { }
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 6c1..bea8d3e 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -26,6 +26,12 @@
 #include 
 #include 
 
+extern const struct hypervisor_x86 x86_hyper_vmware;
+extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
+extern const struct hypervisor_x86 x86_hyper_xen_pv;
+extern const struct hypervisor_x86 x86_hyper_xen_hvm;
+extern const struct hypervisor_x86 x86_hyper_kvm;
+
 static const __initconst struct hypervisor_x86 * const hypervisors[] =
 {
 #ifdef CONFIG_XEN_PV
@@ -41,8 +47,8 @@ static const __initconst struct hypervisor_x86 * const 
hypervisors[] =
 #endif
 };
 
-const struct hypervisor_x86 *x86_hyper;
-EXPORT_SYMBOL(x86_hyper);
+enum x86_hypervisor_type x86_hyper_type;
+EXPORT_SYMBOL(x86_hyper_type);
 
 static inline const struct hypervisor_x86 * __init
 detect_hypervisor_vendor(void)
@@ -87,6 +93,6 @@ void __init init_hypervisor_platform(void)
copy_array(>init, _init.hyper, sizeof(h->init));
copy_array(>runtime, _platform.hyper, sizeof(h->runtime));
 
-   

[tip:x86/timers] x86/tsc: Mark cyc2ns_init() and detect_art() __init

[tip-bot for Dou Liyang]

Commit-ID:  120fc3fbb7787fb70240190cc9c113d1f6523c42
Gitweb: https://git.kernel.org/tip/120fc3fbb7787fb70240190cc9c113d1f6523c42
Author: Dou Liyang 
AuthorDate: Wed, 8 Nov 2017 18:09:52 +0800
Committer:  Ingo Molnar 
CommitDate: Fri, 10 Nov 2017 10:02:08 +0100

x86/tsc: Mark cyc2ns_init() and detect_art() __init

These two functions are only called by tsc_init(), which is an __init
function during boot time, so mark them __init as well.

Signed-off-by: Dou Liyang 
Acked-by: Thomas Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1510135792-17429-1-git-send-email-douly.f...@cn.fujitsu.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/tsc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index f1326c0..416de29 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -112,7 +112,7 @@ static void cyc2ns_data_init(struct cyc2ns_data *data)
data->cyc2ns_offset = 0;
 }
 
-static void cyc2ns_init(int cpu)
+static void __init cyc2ns_init(int cpu)
 {
struct cyc2ns *c2n = _cpu(cyc2ns, cpu);
 
@@ -955,7 +955,7 @@ core_initcall(cpufreq_register_tsc_scaling);
 /*
  * If ART is present detect the numerator:denominator to convert to TSC
  */
-static void detect_art(void)
+static void __init detect_art(void)
 {
unsigned int unused[2];
 

[tip:x86/platform] x86/virt, x86/platform: Merge 'struct x86_hyper' into 'struct x86_platform' and 'struct x86_init'

[tip-bot for Juergen Gross]

Commit-ID:  f72e38e8ec8869ac0ba5a75d7d2f897d98a1454e
Gitweb: https://git.kernel.org/tip/f72e38e8ec8869ac0ba5a75d7d2f897d98a1454e
Author: Juergen Gross 
AuthorDate: Thu, 9 Nov 2017 14:27:35 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 10 Nov 2017 10:03:12 +0100

x86/virt, x86/platform: Merge 'struct x86_hyper' into 'struct x86_platform' and 
'struct x86_init'

Instead of x86_hyper being either NULL on bare metal or a pointer to a
struct hypervisor_x86 in case of the kernel running as a guest merge
the struct into x86_platform and x86_init.

This will remove the need for wrappers making it hard to find out what
is being called. With dummy functions added for all callbacks testing
for a NULL function pointer can be removed, too.

Suggested-by: Ingo Molnar 
Signed-off-by: Juergen Gross 
Acked-by: Thomas Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: akata...@vmware.com
Cc: boris.ostrov...@oracle.com
Cc: de...@linuxdriverproject.org
Cc: haiya...@microsoft.com
Cc: k...@vger.kernel.org
Cc: k...@microsoft.com
Cc: pbonz...@redhat.com
Cc: rkrc...@redhat.com
Cc: ru...@rustcorp.com.au
Cc: sthem...@microsoft.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
Link: http://lkml.kernel.org/r/20171109132739.23465-2-jgr...@suse.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/hypervisor.h | 25 --
 arch/x86/include/asm/x86_init.h   | 24 +
 arch/x86/kernel/apic/apic.c   |  2 +-
 arch/x86/kernel/cpu/hypervisor.c  | 54 +++
 arch/x86/kernel/cpu/mshyperv.c|  2 +-
 arch/x86/kernel/cpu/vmware.c  |  4 +--
 arch/x86/kernel/kvm.c |  2 +-
 arch/x86/kernel/x86_init.c|  9 +++
 arch/x86/mm/init.c|  2 +-
 arch/x86/xen/enlighten_hvm.c  |  8 +++---
 arch/x86/xen/enlighten_pv.c   |  2 +-
 include/linux/hypervisor.h|  8 --
 12 files changed, 81 insertions(+), 61 deletions(-)

diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 0ead9db..0eca723 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -23,6 +23,7 @@
 #ifdef CONFIG_HYPERVISOR_GUEST
 
 #include 
+#include 
 #include 
 
 /*
@@ -35,17 +36,11 @@ struct hypervisor_x86 {
/* Detection routine */
uint32_t(*detect)(void);
 
-   /* Platform setup (run once per boot) */
-   void(*init_platform)(void);
+   /* init time callbacks */
+   struct x86_hyper_init init;
 
-   /* X2APIC detection (run once per boot) */
-   bool(*x2apic_available)(void);
-
-   /* pin current vcpu to specified physical cpu (run rarely) */
-   void(*pin_vcpu)(int);
-
-   /* called during init_mem_mapping() to setup early mappings. */
-   void(*init_mem_mapping)(void);
+   /* runtime callbacks */
+   struct x86_hyper_runtime runtime;
 };
 
 extern const struct hypervisor_x86 *x86_hyper;
@@ -58,17 +53,7 @@ extern const struct hypervisor_x86 x86_hyper_xen_hvm;
 extern const struct hypervisor_x86 x86_hyper_kvm;
 
 extern void init_hypervisor_platform(void);
-extern bool hypervisor_x2apic_available(void);
-extern void hypervisor_pin_vcpu(int cpu);
-
-static inline void hypervisor_init_mem_mapping(void)
-{
-   if (x86_hyper && x86_hyper->init_mem_mapping)
-   x86_hyper->init_mem_mapping();
-}
 #else
 static inline void init_hypervisor_platform(void) { }
-static inline bool hypervisor_x2apic_available(void) { return false; }
-static inline void hypervisor_init_mem_mapping(void) { }
 #endif /* CONFIG_HYPERVISOR_GUEST */
 #endif /* _ASM_X86_HYPERVISOR_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 8a1ebf9..ad15a0f 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -115,6 +115,18 @@ struct x86_init_pci {
 };
 
 /**
+ * struct x86_hyper_init - x86 hypervisor init functions
+ * @init_platform: platform setup
+ * @x2apic_available:  X2APIC detection
+ * @init_mem_mapping:  setup early mappings during init_mem_mapping()
+ */
+struct x86_hyper_init {
+   void (*init_platform)(void);
+   bool (*x2apic_available)(void);
+   void (*init_mem_mapping)(void);
+};
+
+/**
  * struct x86_init_ops - functions for platform specific setup
  *
  */
@@ -127,6 +139,7 @@ struct x86_init_ops {
struct x86_init_timers  timers;
struct x86_init_iommu   iommu;
struct x86_init_pci pci;
+   struct x86_hyper_init   hyper;
 };
 
 /**
@@ -200,6 +213,15 @@ struct x86_legacy_features {
 };
 
 /**
+ * struct x86_hyper_runtime - x86 hypervisor specific runtime callbacks
+ *
+ * @pin_vcpu:  pin current vcpu to specified 

[tip:x86/platform] x86/virt, x86/acpi: Add test for ACPI_FADT_NO_VGA

[tip-bot for Juergen Gross]

Commit-ID:  6d7305254ea947d575a066711c3349fafbebaffa
Gitweb: https://git.kernel.org/tip/6d7305254ea947d575a066711c3349fafbebaffa
Author: Juergen Gross 
AuthorDate: Thu, 9 Nov 2017 14:27:37 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 10 Nov 2017 10:03:13 +0100

x86/virt, x86/acpi: Add test for ACPI_FADT_NO_VGA

Add a test for ACPI_FADT_NO_VGA when scanning the FADT and set the new
flag x86_platform.legacy.no_vga accordingly.

Signed-off-by: Juergen Gross 
Acked-by: Thomas Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: len.br...@intel.com
Cc: linux...@vger.kernel.org
Cc: pa...@ucw.cz
Cc: r...@rjwysocki.net
Link: http://lkml.kernel.org/r/20171109132739.23465-4-jgr...@suse.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/x86_init.h | 1 +
 arch/x86/kernel/acpi/boot.c | 5 +
 2 files changed, 6 insertions(+)

diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index ad15a0f..260e9a8 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -208,6 +208,7 @@ enum x86_legacy_i8042_state {
 struct x86_legacy_features {
enum x86_legacy_i8042_state i8042;
int rtc;
+   int no_vga;
int reserve_bios_regions;
struct x86_legacy_devices devices;
 };
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 079535e..ef9e02e 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -961,6 +961,11 @@ static int __init acpi_parse_fadt(struct acpi_table_header 
*table)
x86_platform.legacy.rtc = 0;
}
 
+   if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_VGA) {
+   pr_debug("ACPI: probing for VGA not safe\n");
+   x86_platform.legacy.no_vga = 1;
+   }
+
 #ifdef CONFIG_X86_PM_TIMER
/* detect the location of the ACPI PM Timer */
if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID) {

Re: [PATCH 3/4] x86/boot/compressed/64: Introduce place_trampoline()

[Kirill A. Shutemov]

On Fri, Nov 10, 2017 at 10:29:33AM +0100, Ingo Molnar wrote:
> 
> * Kirill A. Shutemov  wrote:
> 
> > --- a/arch/x86/boot/compressed/head_64.S
> > +++ b/arch/x86/boot/compressed/head_64.S
> > @@ -315,6 +315,18 @@ ENTRY(startup_64)
> >  * The first step is go into compatibility mode.
> >  */
> >  
> > +   /*
> > +* Find suitable place for trampoline and populate it.
> > +* The address will be stored in RCX.
> > +*
> > +* RSI holds real mode data and need to be preserved across
> > +* a function call.
> > +*/
> > +   pushq   %rsi
> > +   callplace_trampoline
> > +   popq%rsi
> > +   movq%rax, %rcx
> > +
> > /* Clear additional page table */
> > leaqlvl5_pgtable(%rbx), %rdi
> > xorq%rax, %rax
> 
> So in the final version of this code we now have:
> 
>   pushq   %rsi
>   callneed_to_enabled_l5
>   popq%rsi
> 
>   /* If need_to_enabled_l5() returned zero, we're done here. */
>   cmpq$0, %rax
>   je  lvl5
> 
>   /*
>* At this point we are in long mode with 4-level paging enabled,
>* but we want to enable 5-level paging.
>*
>* The problem is that we cannot do it directly. Setting LA57 in
>* long mode would trigger #GP. So we need to switch off long mode
>* first.
>*
>* We use trampoline in lower memory to handle situation when
>* bootloader put the kernel image above 4G.
>*
>* The first step is go into compatibility mode.
>*/
> 
>   /*
>* Find suitable place for trampoline and populate it.
>* The address will be stored in RCX.
>*
>* RSI holds real mode data and need to be preserved across
>* a function call.
>*/
>   pushq   %rsi
>   callplace_trampoline
>   popq%rsi
>   movq%rax, %rcx
> 
> Firstly, the 'need_to_enabled_l5' name sucks because it includes a typo, but 
> also 
> because the prefix is way too generic.
> 
> Something like:
> 
>   l5_paging_required()
> 
> would read a lot better - and would also provide a namespace for all L5 
> paging 
> related functions.
> 
> Secondly, couldn't this be combined into a single .c function, named 
> accordingly:
> 
>   l5_paging_prepare()
> 
> which would return true if L5 paging is available and should be enabled. In 
> this 
> case the trampoline copying function would be called in C, by 
> l5_paging_prepare().
> 
> This further reduces the amount of assembly code.

Makes sense.

-- 
 Kirill A. Shutemov

Re: [PATCH v3 4/4] KVM: Add flush_on_enter before guest enter

[Peter Zijlstra]

On Fri, Nov 10, 2017 at 01:49:47AM -0800, Wanpeng Li wrote:
> @@ -2887,7 +2899,7 @@ static void kvm_steal_time_set_preempted(struct 
> kvm_vcpu *vcpu)
>   if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED))
>   return;
>  
> - vcpu->arch.st.steal.preempted = KVM_VCPU_PREEMPTED;
> + vcpu->arch.st.steal.preempted |= KVM_VCPU_PREEMPTED;

I don't understand this one... If there is concurrency its wrong, if
there is no concurrency it still doesn't make sense as there should not
be any FLUSH flags to preserve..

>  
>   kvm_write_guest_offset_cached(vcpu->kvm, >arch.st.stime,
>   >arch.st.steal.preempted,

Re: [PATCH v3 4/4] KVM: Add flush_on_enter before guest enter

[Peter Zijlstra]

On Fri, Nov 10, 2017 at 11:15:06AM +0100, Paolo Bonzini wrote:
> On 10/11/2017 11:08, Peter Zijlstra wrote:
> > On Fri, Nov 10, 2017 at 01:49:47AM -0800, Wanpeng Li wrote:
> >> @@ -2887,7 +2899,7 @@ static void kvm_steal_time_set_preempted(struct 
> >> kvm_vcpu *vcpu)
> >>if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED))
> >>return;
> >>  
> >> -  vcpu->arch.st.steal.preempted = KVM_VCPU_PREEMPTED;
> >> +  vcpu->arch.st.steal.preempted |= KVM_VCPU_PREEMPTED;
> > 
> > I don't understand this one... If there is concurrency its wrong, if
> > there is no concurrency it still doesn't make sense as there should not
> > be any FLUSH flags to preserve..
> 
> There is no concurrency, foreign VCPUs are not going to write to the
> location unless PREEMPTED is set.  So indeed the "|=" is pointless.
> 
> However, I wonder if it'd be useful for a VCPU to set the bit _on
> itself_ before going to sleep.  Like
> 
> set KVM_VCPU_SHOULD_FLUSH
> hlt
> /* Automagic TLB flush!  */
> 
> This would not work currently, but if it *is* useful, we should make it
> work and document it as legal.  Peter, do you think it would make any sense?

Almost but not quite I think.. So there is no guarantee HLT (or even
MWAIT with a state that has CPUILDE_FLAG_TLB_FLUSHED set) will actually
do the TLB flush.

And if we preempt the vCPU to run a kernel thread we will not in fact
invalidate the TLBs either.

Also, you're confusing the SHOULD_FLUSH with the HAS_FLUSHED concept.
Because if we didn't flush and we should have we should still issue it
on VMENTER.

So if we could somehow tell if a HLT or preemption did indeed flush the
TLBs post fact (reading back the attained C state is possible but really
rather expensive IIRC), then we could set a HAS_FLUSHED flag and avoid
issuing when SHOULD_FLUSH is also set.

Re: [RFC] hv_netvsc: safer orderly shutdown

[Vitaly Kuznetsov]

Stephen Hemminger  writes:

> Several types of control operations require that the underlying RNDIS
> infrastructure be restarted. This patch changes the ordering of the
> shutdown to avoid race conditions.
> Stop all transmits before doing RNDIS halt. This involves stopping the
> network device transmit queues, then waiting for all outstanding
> sends before informing host to halt.
>
> Also, check for successful restart of the device when after the
> change is done.
>
> For review, not tested on Hyper-V yet.
>
> Signed-off-by: Stephen Hemminger 
> ---
>  drivers/net/hyperv/netvsc_drv.c   | 40 
> ++-
>  drivers/net/hyperv/rndis_filter.c | 23 +++---
>  2 files changed, 42 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index da216ca4f2b2..3afa082e093d 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -855,8 +855,10 @@ static int netvsc_set_channels(struct net_device *net,
>
>   orig = nvdev->num_chn;
>   was_opened = rndis_filter_opened(nvdev);
> - if (was_opened)
> + if (was_opened) {
> + netif_tx_disable(net);
>   rndis_filter_close(nvdev);
> + }

I was also experimenting with this and I think it may also make sense to
add napi_disable() for all queues here.

It also seems that the usual TX disable pattern is 

netif_tx_stop_all_queues(net);
netif_tx_disable(net);

not sure why..

>
>   memset(_info, 0, sizeof(device_info));
>   device_info.num_chn = count;
> @@ -881,8 +883,13 @@ static int netvsc_set_channels(struct net_device *net,
>   }
>   }
>
> - if (was_opened)
> - rndis_filter_open(nvdev);
> + if (was_opened) {
> + ret = rndis_filter_open(nvdev);
> + if (ret)
> + netdev_err(net, "reopening device failed: %d\n", ret);
> + else
> + netif_tx_start_all_queues(net);
> + }
>
>   /* We may have missed link change notifications */
>   net_device_ctx->last_reconfig = 0;
> @@ -971,8 +978,10 @@ static int netvsc_change_mtu(struct net_device *ndev, 
> int mtu)
>
>   netif_device_detach(ndev);
>   was_opened = rndis_filter_opened(nvdev);
> - if (was_opened)
> + if (was_opened) {
> + netif_tx_disable(net);
>   rndis_filter_close(nvdev);
> + }

Shall we just nove netif_tx_disable() & friends to rndis_filter_close()?

>
>   memset(_info, 0, sizeof(device_info));
>   device_info.ring_size = ring_size;
> @@ -1004,8 +1013,13 @@ static int netvsc_change_mtu(struct net_device *ndev, 
> int mtu)
>   }
>   }
>
> - if (was_opened)
> - rndis_filter_open(nvdev);
> + if (was_opened) {
> + ret = rndis_filter_open(nvdev);
> + if (ret)
> + netdev_err(net, "reopening device failed: %d\n", ret);
> + else
> + netif_tx_start_all_queues(net);
> + }

Yea, the main problem here is that we can't do much if we fail, the
device will be completely unusable. That's not something users exepct
doing MTU change...

>
>   netif_device_attach(ndev);
>
> @@ -1547,8 +1561,10 @@ static int netvsc_set_ringparam(struct net_device 
> *ndev,
>
>   netif_device_detach(ndev);
>   was_opened = rndis_filter_opened(nvdev);
> - if (was_opened)
> + if (was_opened) {
> + netif_tx_disable(net);
>   rndis_filter_close(nvdev);
> + }
>
>   rndis_filter_device_remove(hdev, nvdev);
>
> @@ -1566,8 +1582,14 @@ static int netvsc_set_ringparam(struct net_device 
> *ndev,
>   }
>   }
>
> - if (was_opened)
> - rndis_filter_open(nvdev);
> + if (was_opened) {
> + ret = rndis_filter_open(nvdev);
> + if (ret)
> + netdev_err(net, "reopening device failed: %d\n", ret);
> + else
> + netif_tx_start_all_queues(net);
> + }
> +
>   netif_device_attach(ndev);
>
>   /* We may have missed link change notifications */
> diff --git a/drivers/net/hyperv/rndis_filter.c 
> b/drivers/net/hyperv/rndis_filter.c
> index 0648eebda829..164f5ffe9c50 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -948,11 +948,20 @@ static void rndis_filter_halt_device(struct 
> rndis_device *dev)
>   struct net_device_context *net_device_ctx = netdev_priv(dev->ndev);
>   struct netvsc_device *nvdev = rtnl_dereference(net_device_ctx->nvdev);
>
> + /* tell bottom half that deice is being closed */
> + nvdev->destroy = true;
> +
> + /* Force flag to be ordered before waiting */
> + wmb();
> +
> + /* Wait for all send completions */
> + wait_event(nvdev->wait_drain, netvsc_device_idle(nvdev));
> +
>   /* 

[PATCH] ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function

[Keerthy]

Referring TRM Am335X series:
http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf

The LastPowerStateEntered bitfield is present only for PM_CEFUSE
domain. This is not present in any of the other power domains. Hence
remove the generic am33xx_pwrdm_read_prev_pwrst hook which wrongly
reads the reserved bit fields for all the other power domains.

Reading the reserved bits leads to wrongly interpreting the low
power transitions for various power domains that do not have the
LastPowerStateEntered field. The pm debug counters values are wrong
currently as we are incrementing them based on the reserved bits.

Signed-off-by: Keerthy 
---
 arch/arm/mach-omap2/prm33xx.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c
index bc5df8d..dfca8d9 100644
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -176,17 +176,6 @@ static int am33xx_pwrdm_read_pwrst(struct powerdomain 
*pwrdm)
return v;
 }
 
-static int am33xx_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
-{
-   u32 v;
-
-   v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs);
-   v &= AM33XX_LASTPOWERSTATEENTERED_MASK;
-   v >>= AM33XX_LASTPOWERSTATEENTERED_SHIFT;
-
-   return v;
-}
-
 static int am33xx_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm)
 {
am33xx_prm_rmw_reg_bits(AM33XX_LOWPOWERSTATECHANGE_MASK,
@@ -386,7 +375,6 @@ struct pwrdm_ops am33xx_pwrdm_operations = {
.pwrdm_set_next_pwrst   = am33xx_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst  = am33xx_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst   = am33xx_pwrdm_read_pwrst,
-   .pwrdm_read_prev_pwrst  = am33xx_pwrdm_read_prev_pwrst,
.pwrdm_set_logic_retst  = am33xx_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = am33xx_pwrdm_read_logic_pwrst,
.pwrdm_read_logic_retst = am33xx_pwrdm_read_logic_retst,
-- 
1.9.1

Re: [PATCH] lib/mpi: call cond_resched() from mpi_powm() loop

[Herbert Xu]

On Mon, Nov 06, 2017 at 10:19:51PM -0800, Eric Biggers wrote:
> From: Eric Biggers 
> 
> On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the
> largest permitted inputs (16384 bits), the kernel spends 10+ seconds
> doing modular exponentiation in mpi_powm() without rescheduling.  If all
> threads do it, it locks up the system.  Moreover, it can cause
> rcu_sched-stall warnings.
> 
> Notwithstanding the insanity of doing this calculation in kernel mode
> rather than in userspace, fix it by calling cond_resched() as each bit
> from the exponent is processed.  It's still noninterruptible, but at
> least it's preemptible now.
> 
> Cc: sta...@vger.kernel.org # v4.12+
> Signed-off-by: Eric Biggers 

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

Re: [PATCH 0/2] hwrng: iproc-rng200: Add support for BCM7278

[Herbert Xu]

On Wed, Nov 01, 2017 at 04:20:04PM -0700, Florian Fainelli wrote:
> Hi,
> 
> This patch series adds support for the RNG200 block found on the BCM7278 SoC.
> This requires us to update the compatible string (and associated binding
> document) as well as the Kconfig option to make that driver selectable with
> ARCH_BRCMSTB gating the enabling of such SoCs.
> 
> Thank you
> 
> Florian Fainelli (2):
>   dt-bindings: rng: Document BCM7278 RNG200 compatible
>   hwrng: iproc-rng200: Add support for BCM7278

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

[PATCH v8 6/7] arm64: kvm: Set Virtual SError Exception Syndrome for guest

[Dongjiu Geng]

RAS Extension add a VSESR_EL2 register which can provides
the syndrome value reported to software on taking a virtual
SError interrupt exception. This patch supports to specify
this Syndrome.

In the RAS Extensions we can not set all-zero syndrome value
for SError, which means 'RAS error: Uncategorized' instead of
'no valid ISS'. So set it to IMPLEMENTATION DEFINED syndrome
by default.

We also need to support userspace to specify a valid syndrome
value, Because in some case, the recovery is driven by userspace.
This patch can support that userspace can specify it.

In the guest/host world switch, restore this value to VSESR_EL2
only when HCR_EL2.VSE is set. This value no need to be saved
because it is stale vale when guest exit.

Signed-off-by: Dongjiu Geng 
Signed-off-by: Quanming Wu 
[Set an impdef ESR for Virtual-SError]
Signed-off-by: James Morse 
---
 arch/arm64/include/asm/kvm_emulate.h | 10 ++
 arch/arm64/include/asm/kvm_host.h|  1 +
 arch/arm64/include/asm/sysreg.h  |  3 +++
 arch/arm64/kvm/guest.c   | 11 ++-
 arch/arm64/kvm/hyp/switch.c  | 16 
 arch/arm64/kvm/inject_fault.c| 13 -
 6 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_emulate.h 
b/arch/arm64/include/asm/kvm_emulate.h
index 555b28b..73c84d0 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -155,6 +155,16 @@ static inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu 
*vcpu)
return vcpu->arch.fault.esr_el2;
 }
 
+static inline u32 kvm_vcpu_get_vsesr(const struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.fault.vsesr_el2;
+}
+
+static inline void kvm_vcpu_set_vsesr(struct kvm_vcpu *vcpu, unsigned long val)
+{
+   vcpu->arch.fault.vsesr_el2 = val;
+}
+
 static inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
 {
u32 esr = kvm_vcpu_get_hsr(vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index 769cc58..53d1d81 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -88,6 +88,7 @@ struct kvm_vcpu_fault_info {
u32 esr_el2;/* Hyp Syndrom Register */
u64 far_el2;/* Hyp Fault Address Register */
u64 hpfar_el2;  /* Hyp IPA Fault Address Register */
+   u32 vsesr_el2;  /* Virtual SError Exception Syndrome Register */
 };
 
 /*
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 47b967d..3b035cc 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -86,6 +86,9 @@
 #define REG_PSTATE_PAN_IMM sys_reg(0, 0, 4, 0, 4)
 #define REG_PSTATE_UAO_IMM sys_reg(0, 0, 4, 0, 3)
 
+/* virtual SError exception syndrome register */
+#define REG_VSESR_EL2  sys_reg(3, 4, 5, 2, 3)
+
 #define SET_PSTATE_PAN(x) __emit_inst(0xd500 | REG_PSTATE_PAN_IMM |
\
  (!!x)<<8 | 0x1f)
 #define SET_PSTATE_UAO(x) __emit_inst(0xd500 | REG_PSTATE_UAO_IMM |
\
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 738ae90..ffad42b 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -279,7 +279,16 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
 
 int kvm_arm_set_sei_esr(struct kvm_vcpu *vcpu, u32 *syndrome)
 {
-   return -EINVAL;
+   u64 reg = *syndrome;
+
+   /* inject virtual system Error or asynchronous abort */
+   kvm_inject_vabt(vcpu);
+
+   if (reg)
+   /* set vsesr_el2[24:0] with value that user space specified */
+   kvm_vcpu_set_vsesr(vcpu, reg & ESR_ELx_ISS_MASK);
+
+   return 0;
 }
 
 int __attribute_const__ kvm_target_cpu(void)
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index c6f17c7..06a71d2 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -67,6 +67,14 @@ static hyp_alternate_select(__activate_traps_arch,
__activate_traps_nvhe, __activate_traps_vhe,
ARM64_HAS_VIRT_HOST_EXTN);
 
+static void __hyp_text __sysreg_set_vsesr(struct kvm_vcpu *vcpu, u64 value)
+{
+   if (cpus_have_const_cap(ARM64_HAS_RAS_EXTN) &&
+  (value & HCR_VSE))
+   write_sysreg_s(kvm_vcpu_get_vsesr(vcpu), REG_VSESR_EL2);
+}
+
+
 static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 {
u64 val;
@@ -86,6 +94,14 @@ static void __hyp_text __activate_traps(struct kvm_vcpu 
*vcpu)
isb();
}
write_sysreg(val, hcr_el2);
+
+   /*
+* If the virtual SError interrupt is taken to EL1 using AArch64,
+* then VSESR_EL2 provides the syndrome value reported in ISS field
+* of ESR_EL1.
+*/
+   __sysreg_set_vsesr(vcpu, val);
+

[PATCH v8 1/7] arm64: cpufeature: Detect CPU RAS Extentions

[Dongjiu Geng]

From: Xie XiuQi 

ARM's v8.2 Extentions add support for Reliability, Availability and
Serviceability (RAS). On CPUs with these extensions system software
can use additional barriers to isolate errors and determine if faults
are pending.

Add cpufeature detection and a barrier in the context-switch code.
There is no need to use alternatives for this as CPUs that don't
support this feature will treat the instruction as a nop.

Platform level RAS support may require additional firmware support.

Signed-off-by: Xie XiuQi 
[Rebased, added esb and config option, reworded commit message]
Signed-off-by: James Morse 
Signed-off-by: Dongjiu Geng 
Reviewed-by: Catalin Marinas 
---
 arch/arm64/Kconfig   | 16 
 arch/arm64/include/asm/barrier.h |  1 +
 arch/arm64/include/asm/cpucaps.h |  3 ++-
 arch/arm64/include/asm/sysreg.h  |  2 ++
 arch/arm64/kernel/cpufeature.c   | 13 +
 arch/arm64/kernel/process.c  |  3 +++
 6 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0df64a6..cc00d10 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -973,6 +973,22 @@ config ARM64_PMEM
  operations if DC CVAP is not supported (following the behaviour of
  DC CVAP itself if the system does not define a point of persistence).
 
+config ARM64_RAS_EXTN
+   bool "Enable support for RAS CPU Extensions"
+   default y
+   help
+ CPUs that support the Reliability, Availability and Serviceability
+ (RAS) Extensions, part of ARMv8.2 are able to track faults and
+ errors, classify them and report them to software.
+
+ On CPUs with these extensions system software can use additional
+ barriers to determine if faults are pending and read the
+ classification from a new set of registers.
+
+ Selecting this feature will allow the kernel to use these barriers
+ and access the new registers if the system supports the extension.
+ Platform RAS features may additionally depend on firmware support.
+
 endmenu
 
 config ARM64_MODULE_CMODEL_LARGE
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 0fe7e43..8b0a0eb 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -30,6 +30,7 @@
 #define isb()  asm volatile("isb" : : : "memory")
 #define dmb(opt)   asm volatile("dmb " #opt : : : "memory")
 #define dsb(opt)   asm volatile("dsb " #opt : : : "memory")
+#define esb()  asm volatile("hint #16"  : : : "memory")
 
 #define mb()   dsb(sy)
 #define rmb()  dsb(ld)
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 8da6216..4820d44 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -40,7 +40,8 @@
 #define ARM64_WORKAROUND_85892119
 #define ARM64_WORKAROUND_CAVIUM_30115  20
 #define ARM64_HAS_DCPOP21
+#define ARM64_HAS_RAS_EXTN 22
 
-#define ARM64_NCAPS22
+#define ARM64_NCAPS23
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index f707fed..64e2a80 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -332,6 +332,7 @@
 #define ID_AA64ISAR1_DPB_SHIFT 0
 
 /* id_aa64pfr0 */
+#define ID_AA64PFR0_RAS_SHIFT  28
 #define ID_AA64PFR0_GIC_SHIFT  24
 #define ID_AA64PFR0_ASIMD_SHIFT20
 #define ID_AA64PFR0_FP_SHIFT   16
@@ -340,6 +341,7 @@
 #define ID_AA64PFR0_EL1_SHIFT  4
 #define ID_AA64PFR0_EL0_SHIFT  0
 
+#define ID_AA64PFR0_RAS_V1 0x1
 #define ID_AA64PFR0_FP_NI  0xf
 #define ID_AA64PFR0_FP_SUPPORTED   0x0
 #define ID_AA64PFR0_ASIMD_NI   0xf
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 21e2c95..4846974 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -125,6 +125,7 @@ static int __init register_cpu_hwcaps_dumper(void)
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
+   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 
ID_AA64PFR0_RAS_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, 
ID_AA64PFR0_GIC_SHIFT, 4, 0),
S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64PFR0_FP_SHIFT, 4, ID_AA64PFR0_FP_NI),
@@ -900,6 +901,18 @@ static bool has_no_fpsimd(const struct 
arm64_cpu_capabilities *entry, int __unus
.min_field_value = 1,
},
 #endif
+#ifdef CONFIG_ARM64_RAS_EXTN
+   {
+   

[PATCH v8 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

[Dongjiu Geng]

The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the
guest and user space needs a way to tell KVM this value. So we add a
new ioctl. Before user space specifies the Exception Syndrome Register
ESR(ESR), it firstly checks that whether KVM has the capability to
set the guest ESR, If has, will set it. Otherwise, nothing to do.

For this ESR specifying, Only support for AArch64, not support AArch32.

Signed-off-by: Dongjiu Geng 
Signed-off-by: Quanming Wu 

change the name to KVM_CAP_ARM_INJECT_SERROR_ESR instead of
X_ARM_RAS_EXTENSION, suggested here

https://patchwork.kernel.org/patch/9925203/
---
 Documentation/virtual/kvm/api.txt | 11 +++
 arch/arm/include/asm/kvm_host.h   |  1 +
 arch/arm/kvm/guest.c  |  9 +
 arch/arm64/include/asm/kvm_host.h |  1 +
 arch/arm64/kvm/guest.c|  5 +
 arch/arm64/kvm/reset.c|  3 +++
 include/uapi/linux/kvm.h  |  3 +++
 virt/kvm/arm/arm.c|  7 +++
 8 files changed, 40 insertions(+)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index e63a35f..6dfb9fc 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4347,3 +4347,14 @@ This capability indicates that userspace can load 
HV_X64_MSR_VP_INDEX msr.  Its
 value is used to denote the target vcpu for a SynIC interrupt.  For
 compatibilty, KVM initializes this msr to KVM's internal vcpu index.  When this
 capability is absent, userspace can still query this msr's value.
+
+8.13 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify syndrome value reported to
+guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the 
ESR
+syndrome, can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be 
reported
+into ISS filed of ESR_EL1
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 4a879f6..6cf5c7b 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -211,6 +211,7 @@ struct kvm_vcpu_stat {
 int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
 int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
 int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_set_sei_esr(struct kvm_vcpu *vcpu, u32 *syndrome);
 unsigned long kvm_call_hyp(void *hypfn, ...);
 void force_vm_exit(const cpumask_t *mask);
 
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 1e0784e..1e15fa2 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -248,6 +248,15 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
 }
 
+/*
+ * we only support guest SError syndrome specifying
+ * for ARM64, not support it for ARM32.
+ */
+int kvm_arm_set_sei_esr(struct kvm_vcpu *vcpu, u32 *syndrome)
+{
+   return -EINVAL;
+}
+
 int __attribute_const__ kvm_target_cpu(void)
 {
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index e923b58..769cc58 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -317,6 +317,7 @@ struct kvm_vcpu_stat {
 int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
 int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
 int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_set_sei_esr(struct kvm_vcpu *vcpu, u32 *syndrome);
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
 int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 5c7f657..738ae90 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -277,6 +277,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
 }
 
+int kvm_arm_set_sei_esr(struct kvm_vcpu *vcpu, u32 *syndrome)
+{
+   return -EINVAL;
+}
+
 int __attribute_const__ kvm_target_cpu(void)
 {
unsigned long implementor = read_cpuid_implementor();
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long 
ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+   case KVM_CAP_ARM_INJECT_SERROR_ESR:
+   r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+   break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 7e9..0c861c4 100644
--- a/include/uapi/linux/kvm.h
+++ 

Welcome!

[Ailyn Alberca Rubin]

Hello dear, compliments of the season, I sent series of mail, have you
seen them ?

Re: [RFC v4 13/17] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

2017-10-25 Brian Starkey :

> Hi Gustavo,
> 
> On Fri, Oct 20, 2017 at 07:50:08PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > Receive in-fence from userspace and add support for waiting on them
> > before queueing the buffer to the driver. Buffers are only queued
> > to the driver once they are ready. A buffer is ready when its
> > in-fence signals.
> > 
> > For queues that require vb2 to queue buffers to the v4l2 driver in same
> > order they are received from userspace we use fence_array to keep that
> > ordering. Basically we create a fence_array that contains both the current
> > fence and the fence from the previous buffer (which might be a fence array
> > as well). The base fence class for the fence_array becomes the new buffer
> > fence, waiting on that one guarantees that it won't be queued out of
> > order.
> 
> The API sounds/looks good to me, makes sense to let driver opt in/out
> via the ordered_in_vb2 thing. Thanks for implementing it!
> 
> > 
> > v5: - use fence_array to keep buffers ordered in vb2 core when
> > needed (Brian Stark)
> > - keep backward compatibility on the reserved2 field (Brian Stark)
> > - protect fence callback removal with lock (Brian Stark)
> 
> Brian Starkey, but close ;-)
> 
> > 
> > v4:
> > - Add a comment about dma_fence_add_callback() not returning a
> > error (Hans)
> > - Call dma_fence_put(vb->in_fence) if fence signaled (Hans)
> > - select SYNC_FILE under config VIDEOBUF2_CORE (Hans)
> > - Move dma_fence_is_signaled() check to __enqueue_in_driver() (Hans)
> > - Remove list_for_each_entry() in __vb2_core_qbuf() (Hans)
> > -  Remove if (vb->state != VB2_BUF_STATE_QUEUED) from
> > vb2_start_streaming() (Hans)
> > - set IN_FENCE flags on __fill_v4l2_buffer (Hans)
> > - Queue buffers to the driver as soon as they are ready (Hans)
> > - call fill_user_buffer() after queuing the buffer (Hans)
> > - add err: label to clean up fence
> > - add dma_fence_wait() before calling vb2_start_streaming()
> > 
> > v3: - document fence parameter
> > - remove ternary if at vb2_qbuf() return (Mauro)
> > - do not change if conditions behaviour (Mauro)
> > 
> > v2:
> > - fix vb2_queue_or_prepare_buf() ret check
> > - remove check for VB2_MEMORY_DMABUF only (Javier)
> > - check num of ready buffers to start streaming
> > - when queueing, start from the first ready buffer
> > - handle queue cancel
> > 
> > Signed-off-by: Gustavo Padovan 
> > ---
> > drivers/media/v4l2-core/Kconfig  |   1 +
> > drivers/media/v4l2-core/videobuf2-core.c | 179 
> > ---
> > drivers/media/v4l2-core/videobuf2-v4l2.c |  29 -
> > include/media/videobuf2-core.h   |  17 ++-
> > 4 files changed, 208 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/Kconfig 
> > b/drivers/media/v4l2-core/Kconfig
> > index a35c33686abf..3f988c407c80 100644
> > --- a/drivers/media/v4l2-core/Kconfig
> > +++ b/drivers/media/v4l2-core/Kconfig
> > @@ -83,6 +83,7 @@ config VIDEOBUF_DVB
> > # Used by drivers that need Videobuf2 modules
> > config VIDEOBUF2_CORE
> > select DMA_SHARED_BUFFER
> > +   select SYNC_FILE
> > tristate
> > 
> > config VIDEOBUF2_MEMOPS
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 60f8b582396a..78f369dba3e3 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -346,6 +346,7 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> > vb2_memory memory,
> > vb->index = q->num_buffers + buffer;
> > vb->type = q->type;
> > vb->memory = memory;
> > +   spin_lock_init(>fence_cb_lock);
> > for (plane = 0; plane < num_planes; ++plane) {
> > vb->planes[plane].length = plane_sizes[plane];
> > vb->planes[plane].min_length = plane_sizes[plane];
> > @@ -1222,6 +1223,9 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
> > {
> > struct vb2_queue *q = vb->vb2_queue;
> > 
> > +   if (vb->in_fence && !dma_fence_is_signaled(vb->in_fence))
> > +   return;
> > +
> > vb->state = VB2_BUF_STATE_ACTIVE;
> > atomic_inc(>owned_by_drv_count);
> > 
> > @@ -1273,6 +1277,20 @@ static int __buf_prepare(struct vb2_buffer *vb, 
> > const void *pb)
> > return 0;
> > }
> > 
> > +static int __get_num_ready_buffers(struct vb2_queue *q)
> > +{
> > +   struct vb2_buffer *vb;
> > +   int ready_count = 0;
> > +
> > +   /* count num of buffers ready in front of the queued_list */
> > +   list_for_each_entry(vb, >queued_list, queued_entry) {
> > +   if (!vb->in_fence || dma_fence_is_signaled(vb->in_fence))
> > +   ready_count++;
> 
> I think there's still some races on vb->in_fence. Couldn't the
> 

Re: [PATCH v5 2/3] x86/topology: Avoid wasting 128k for package id array

[Thomas Gleixner]

On Fri, 10 Nov 2017, Prarit Bhargava wrote:
> On 11/09/2017 07:43 PM, Thomas Gleixner wrote:
> > On Sun, 5 Nov 2017, Prarit Bhargava wrote:
> >> [v5]: Change kmalloc to GFP_ATOMIC to fix "sleeping function" warning on
> >> virtual machines.
> > 
> > What has this to do with virtual machines? The very same issue is on
> > physcial hardware because this is called from the early CPU bringup code
> > with interrupts and preemption disabled.
> 
> There was a Intel test bot report of a failure during boot on virtual systems
> with Andi's patch.

Sure, but the problem has nothing to do with virtual machines at all.

Thanks,

tglx

Re: [PATCH V13 08/10] mmc: block: blk-mq: Separate card polling from recovery

[Linus Walleij]

On Thu, Nov 9, 2017 at 2:02 PM, Adrian Hunter  wrote:
> On 09/11/17 14:52, Linus Walleij wrote:
>> On Thu, Nov 9, 2017 at 8:56 AM, Adrian Hunter  
>> wrote:
>>> On 08/11/17 11:30, Linus Walleij wrote:
 On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter  
 wrote:

> Recovery is simpler to understand if it is only used for errors. Create a
> separate function for card polling.
>
> Signed-off-by: Adrian Hunter 

 This looks good but I can't see why it's not folded into
 patch 3 already. This error handling is introduced there.
>>>
>>> What are you on about?
>>
>> You are attacking your most valuable resource, a reviewer.
>>
>> And I even said the patch looks good.
>>
>> The only thing you attain with this kind of langauge is alienante
>> me and discourage others to review your patch set. You also
>> give your employer a bad name, since you are representing
>> them.
>
> 6 months of being messed around will do that.

Blessed are the meek, for they will inherit the earth.

Nobody is after you, this is just hard stuff and too few people care to
help out with review etc. With this and with the block layer as well.
That makes things slow. It's noone's agenda to slow things down.

Yours,
Linus Walleij

Re: [PATCH 26/31] nds32: Build infrastructure

[Greentime Hu]

2017-11-09 18:33 GMT+08:00 Arnd Bergmann :
> On Thu, Nov 9, 2017 at 10:02 AM, Greentime Hu  wrote:
>> 2017-11-08 18:16 GMT+08:00 Arnd Bergmann :
>>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu  wrote:
>
 +config GENERIC_CALIBRATE_DELAY
 +   def_bool y
>>>
>>> It's better to avoid the delay loop completely and skip the calibration,
>>> if your hardware allows.
>>
>> Thanks.
>> Do you mean that this config should be def_bool n?
>> why? Almost all arch enable it.
>
> It depends on what your hardware can do. If you have a way to see how much
> time has passed that is guaranteed to be reliable on all machines, then
> use that instead.
>
> On a lot of architectures, it's not possible, so they have to fall back to 
> using
> the delay loop.

I get it. I will discuss it with our HW colleagues.
We may get these informations in some registers.

 +config ALIGNMENT_TRAP
 +   tristate "Kernel support unaligned access handling"
 +   default y
 +   help
 + Andes processors cannot fetch/store information which is not
 + naturally aligned on the bus, i.e., a 4 byte fetch must start at 
 an
 + address divisible by 4. On 32-bit Andes processors, these 
 non-aligned
 + fetch/store instructions will be emulated in software if you say
 + here, which has a severe performance impact. This is necessary 
 for
 + correct operation of some network protocols. With an IP-only
 + configuration it is safe to say N, otherwise say Y.
>>>
>>> Which network protocols are you referring to?
>>
>> I will modify these descriptions. It was written by someone I don't know. :p
>> This case only happened when I found is compiler code gen issue or
>> wrong pointer usage.
>
> Ok, should it also be 'default n' then?

Yup. I will use 'default n' in the next version patch.

 +config HIGHMEM
 +   bool "High Memory Support"
 +   depends on MMU && CPU_CACHE_NONALIASING
 +   help
 + The address space of Andes processors is only 4 Gigabytes large
 + and it has to accommodate user address space, kernel address
 + space as well as some memory mapped IO. That means that, if you
 + have a large amount of physical memory and/or IO, not all of the
 + memory can be "permanently mapped" by the kernel. The physical
 + memory that is not permanently mapped is called "high memory".
 +
 + Depending on the selected kernel/user memory split, minimum
 + vmalloc space and actual amount of RAM, you may not need this
 + option which should result in a slightly faster kernel.
 +
 + If unsure, say N.
>>>
>>> Generally speaking, highmem support is a mess, and it's better to avoid it.
>>>
>>> I see that the two device tree files you have list 1GB of memory. Do you 
>>> think
>>> that is a common configuration for actual products? Do you expect any to
>>> have more than 1GB (or more than 4GB) in the future, or is that the upper
>>> end of the scale?
>>>
>>> If 1GB is a reasonable upper bound, then you could change the vmsplit
>>> to give slightly less address space to user space and have 1GB of 
>>> direct-mapped
>>> kernel memory plus 256MB of vmalloc space reserved for the kernel,
>>> and completely avoid highmem.
>>
>> Thanks.
>> We do realy use 1GB ram in some products.
>> We also verify CONFIG_HIGHMEM with LTP too.
>> It seems fine but I will study vmsplit to see if we should use it.
>
> For the 1GB configuration, something like ARM's CONFIG_VMSPLIT_3G_OPT
> should be optimal, it will result in better performance because it allows you
> to completely turn off CONFIG_HIGHMEM. The reason we don't always
> use it on ARM is that traditionally we had the 3GB vmsplit, and some
> applications
> might rely on having the exact amount of available address space that they
> expect. For a new architecture that should be less of a problem.
>
> The interesting case is what happens if you have machines with 1.5GB or
> or more physical RAM. You can obviously have another vmsplit configuration
> for those, but at some point going to highmem is better than limiting the
> user address space.
>
> Ideally 1.5GB is the point where you start using a 64-bit CPU, but of course
> that is not something you have available at the moment.



 +config MEMORY_START
 +   hex "Physical memory start address"
 +   default "0x"
 +   help
 + Physical memory start address, you may modify it if it is 
 porting to
 + a new SoC with different start address.
 +endmenu
>>>
>>> On ARM, we found options like this to be rather problematic since it 
>>> prevents
>>> you from running the same kernel on boards that are otherwise compatible.
>>>
>>> If the architecture easily allows the memory to start 

Re: [PATCH v2] fs: guard_bio_eod() needs to consider partitions

[Christoph Hellwig]

This looks good to me:

Reviewed-by: Christoph Hellwig 

Jens, can you pick it up through the block tree given that is where
the issue was introduced?

[PATCH 1/3] dt-bindings: reset: Add bindings for the Meson-AXG SoC Reset Controller

[Yixun Lan]

Add DT bindings for the Meson-AXG SoC Reset Controller include file,
and also slightly update documentation.

Signed-off-by: Yixun Lan 
---
 .../bindings/reset/amlogic,meson-reset.txt |   3 +-
 .../dt-bindings/reset/amlogic,meson-axg-reset.h| 124 +
 2 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/reset/amlogic,meson-axg-reset.h

diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt 
b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
index e746b631793a..28ef6c295c76 100644
--- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
+++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
@@ -5,7 +5,8 @@ Please also refer to reset.txt in this directory for common 
reset
 controller binding usage.
 
 Required properties:
-- compatible: Should be "amlogic,meson8b-reset" or "amlogic,meson-gxbb-reset"
+- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset" or
+   "amlogic,meson-axg-reset".
 - reg: should contain the register address base
 - #reset-cells: 1, see below
 
diff --git a/include/dt-bindings/reset/amlogic,meson-axg-reset.h 
b/include/dt-bindings/reset/amlogic,meson-axg-reset.h
new file mode 100644
index ..ad6f55dabd6d
--- /dev/null
+++ b/include/dt-bindings/reset/amlogic,meson-axg-reset.h
@@ -0,0 +1,124 @@
+/*
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * Copyright (c) 2017 Amlogic, inc.
+ * Author: Yixun Lan 
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR BSD)
+ */
+
+#ifndef _DT_BINDINGS_AMLOGIC_MESON_AXG_RESET_H
+#define _DT_BINDINGS_AMLOGIC_MESON_AXG_RESET_H
+
+/* RESET0  */
+#define RESET_HIU  0
+#define RESET_PCIE_A   1
+#define RESET_PCIE_B   2
+#define RESET_DDR_TOP  3
+/* 4   */
+#define RESET_VIU  5
+#define RESET_PCIE_PHY 6
+#define RESET_PCIE_APB 7
+/* 8   */
+/* 9   */
+#define RESET_VENC 10
+#define RESET_ASSIST   11
+/* 12  */
+#define RESET_VCBUS13
+/* 14  */
+/* 15  */
+#define RESET_GIC  16
+#define RESET_CAPB3_DECODE 17
+/* 18-21   */
+#define RESET_SYS_CPU_CAPB322
+#define RESET_CBUS_CAPB3   23
+#define RESET_AHB_CNTL 24
+#define RESET_AHB_DATA 25
+#define RESET_VCBUS_CLK81  26
+#define RESET_MMC  27
+/* 28-31   */
+/* RESET1  */
+/* 32  */
+/* 33  */
+#define RESET_USB_OTG  34
+#define RESET_DDR  35
+#define RESET_AO_RESET 36
+/* 37  */
+#define RESET_AHB_SRAM 38
+/* 39  */
+/* 40  */
+#define RESET_DMA  41
+#define RESET_ISA  42
+#define RESET_ETHERNET 43
+/* 44  */
+#define RESET_SD_EMMC_B45
+#define RESET_SD_EMMC_C46
+#define RESET_ROM_BOOT 47
+#define RESET_SYS_CPU_048
+#define RESET_SYS_CPU_149
+#define RESET_SYS_CPU_250
+#define RESET_SYS_CPU_351
+#define RESET_SYS_CPU_CORE_0   52
+#define RESET_SYS_CPU_CORE_1   53
+#define RESET_SYS_CPU_CORE_2   54
+#define RESET_SYS_CPU_CORE_3   55
+#define RESET_SYS_PLL_DIV  56
+#define RESET_SYS_CPU_AXI  57
+#define RESET_SYS_CPU_L2   58
+#define RESET_SYS_CPU_P59
+#define RESET_SYS_CPU_MBIST60
+/* 61-63   */
+/* RESET2  */
+/* 64  */
+/* 65  */
+#define RESET_AUDIO66
+/* 67  */
+#define RESET_MIPI_HOST68
+#define RESET_AUDIO_LOCKER 69
+#define RESET_GE2D 70
+/* 71-76   */
+#define RESET_AO_CPU_RESET 77
+/* 78-95   */
+/* RESET3  

[PATCH 0/3] add Reset controller driver for Meson-AXG

[Yixun Lan]

This patches add the Reset controller driver which found at
the Amlogic Meson-AXG SoC.

Yixun Lan (3):
  dt-bindings: reset: Add bindings for the Meson-AXG SoC Reset
Controller
  reset: meson-axg: add compatible string for Meson-AXG SoC
  arm64: dts: meson-axg: add new reset DT node

 .../bindings/reset/amlogic,meson-reset.txt |   3 +-
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi |   6 +
 drivers/reset/reset-meson.c|   2 +
 .../dt-bindings/reset/amlogic,meson-axg-reset.h| 124 +
 4 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/reset/amlogic,meson-axg-reset.h

-- 
2.14.1

[PATCH 2/3] reset: meson-axg: add compatible string for Meson-AXG SoC

[Yixun Lan]

Try to add compatible string explictly to support new Meson-AXG SoC.

Signed-off-by: Yixun Lan 
---
 drivers/reset/reset-meson.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
index c419a3753d00..93cbee1ae8ef 100644
--- a/drivers/reset/reset-meson.c
+++ b/drivers/reset/reset-meson.c
@@ -139,6 +139,8 @@ static const struct of_device_id meson_reset_dt_ids[] = {
   .data = _reset_meson8_ops, },
 { .compatible = "amlogic,meson-gxbb-reset",
   .data = _reset_gx_ops, },
+{ .compatible = "amlogic,meson-axg-reset",
+  .data = _reset_gx_ops, },
 { /* sentinel */ },
 };
 
-- 
2.14.1

[PATCH 3/3] arm64: dts: meson-axg: add new reset DT node

[Yixun Lan]

Add reset DT node for Amlogic's Meson-AXG SoC.

Signed-off-by: Yixun Lan 
---
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index e0fb860e12c5..65945c6c8b65 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -123,6 +123,12 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xffd0 0x0 0x25000>;
 
+   reset: reset-controller@1004 {
+   compatible = "amlogic,meson-axg-reset";
+   reg = <0x0 0x01004 0x0 0x9c>;
+   #reset-cells = <1>;
+   };
+
uart_A: serial@24000 {
compatible = "amlogic,meson-gx-uart", 
"amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
-- 
2.14.1

Re: [PATCH] rtc: Use time64_t variables to set time/alarm from sysfs

[Alexandre Belloni]

On 09/11/2017 at 15:09:20 +0800, Baolin Wang wrote:
> Use time64_t variables and related APIs for sysfs interfaces to
> support setting time or alarm after the year 2038 on 32-bit system.
> 
> Signed-off-by: Baolin Wang 
> ---
>  drivers/rtc/rtc-sysfs.c |   25 +
>  1 file changed, 13 insertions(+), 12 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v5 16/26] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs

[Marc Zyngier]

On 10/11/17 08:37, Christoffer Dall wrote:
> On Wed, Nov 08, 2017 at 03:08:36PM +, Marc Zyngier wrote:
>> On 07/11/17 21:28, Auger Eric wrote:
>>> Hi Marc,
>>>
>>> On 27/10/2017 16:28, Marc Zyngier wrote:
 Upon updating a property, we propagate it all the way to the physical
 ITS, and ask for an INV command to be executed there.

 Acked-by: Christoffer Dall 
 Signed-off-by: Marc Zyngier 
 ---
  virt/kvm/arm/vgic/vgic-its.c | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
 index 0b7e648e7a0c..2e77c7c83942 100644
 --- a/virt/kvm/arm/vgic/vgic-its.c
 +++ b/virt/kvm/arm/vgic/vgic-its.c
 @@ -296,6 +296,9 @@ static int update_lpi_config(struct kvm *kvm, struct 
 vgic_irq *irq,
spin_unlock(>irq_lock);
}
  
 +  if (irq->hw)
 +  return its_prop_update_vlpi(irq->host_irq, prop, true);
 +
return 0;
  }
>>> I am confused by the vgic_queue_irq_unlock() on the "hw" path. Why is it
>>> needed in hw mode?
>>
>> It's not. I guess we could bypass this altogether and take a short cut
>> after having updated the priority and enabled fields.
>>
> 
> I can apply this on top of the series as well if you're happy with it:
> 
> commit b54fba93b1330803a59ca75f3a5102e22cadc871 (HEAD -> next-gicv4)
> Author: Christoffer Dall 
> Date:   Fri Nov 10 09:34:54 2017 +0100
> 
> KVM: arm/arm64: Don't queue VLPIs on INV/INVALL
> 
> Since VLPIs are injected directly by the hardware there's no need to
> mark these as pending in software and queue them on the AP list.
> 
> Signed-off-by: Christoffer Dall 
> 
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index c93ecd4a903b..a3754ec719c4 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -292,11 +292,14 @@ static int update_lpi_config(struct kvm *kvm, struct 
> vgic_irq *irq,
>   irq->priority = LPI_PROP_PRIORITY(prop);
>   irq->enabled = LPI_PROP_ENABLE_BIT(prop);
>  
> - vgic_queue_irq_unlock(kvm, irq, flags);
> - } else {
> - spin_unlock_irqrestore(>irq_lock, flags);
> + if (!irq->hw) {
> + vgic_queue_irq_unlock(kvm, irq, flags);
> + return 0;
> + }
>   }
>  
> + spin_unlock_irqrestore(>irq_lock, flags);
> +
>   if (irq->hw)
>   return its_prop_update_vlpi(irq->host_irq, prop, needs_inv);
>  

Reviewed-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v5 10/26] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass

[Marc Zyngier]

On 10/11/17 08:28, Christoffer Dall wrote:
> Hi Eric and Marc,
> 
> On Tue, Nov 07, 2017 at 02:42:44PM +, Marc Zyngier wrote:
>> Hi Eric,
>>
>> On 07/11/17 13:06, Auger Eric wrote:
>>> Hi Marc,
>>>
>>> On 27/10/2017 16:28, Marc Zyngier wrote:
 Let's use the irq bypass mechanism introduced for platform device
 interrupts
>>> nit: I would remove "introduced for platform device interrupts"
>>> as this is not upstream yet. x86 posted interrupts also use it.
>>>

>>>  and establish our LPI->VLPI mapping.
> 
> I have tweaked the commit message.
> 

 Reviewed-by: Christoffer Dall 
 Signed-off-by: Marc Zyngier 
 ---
  include/kvm/arm_vgic.h  |   8 
  virt/kvm/arm/arm.c  |   6 ++-
  virt/kvm/arm/vgic/vgic-v4.c | 108 
 
  3 files changed, 120 insertions(+), 2 deletions(-)

 diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
 index 7eeb6c2a2f9c..2f750c770bf2 100644
 --- a/include/kvm/arm_vgic.h
 +++ b/include/kvm/arm_vgic.h
 @@ -373,4 +373,12 @@ int kvm_vgic_setup_default_irq_routing(struct kvm 
 *kvm);
  
  int kvm_vgic_set_owner(struct kvm_vcpu *vcpu, unsigned int intid, void 
 *owner);
  
 +struct kvm_kernel_irq_routing_entry;
 +
 +int kvm_vgic_v4_set_forwarding(struct kvm *kvm, int irq,
 + struct kvm_kernel_irq_routing_entry *irq_entry);
 +
 +int kvm_vgic_v4_unset_forwarding(struct kvm *kvm, int irq,
 +   struct kvm_kernel_irq_routing_entry 
 *irq_entry);
 +
  #endif /* __KVM_ARM_VGIC_H */
 diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
 index 5d5218ecd547..8388c1cc23f6 100644
 --- a/virt/kvm/arm/arm.c
 +++ b/virt/kvm/arm/arm.c
 @@ -1462,7 +1462,8 @@ int kvm_arch_irq_bypass_add_producer(struct 
 irq_bypass_consumer *cons,
struct kvm_kernel_irqfd *irqfd =
container_of(cons, struct kvm_kernel_irqfd, consumer);
  
 -  return 0;
 +  return kvm_vgic_v4_set_forwarding(irqfd->kvm, prod->irq,
 +>irq_entry);
  }
  void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
  struct irq_bypass_producer *prod)
 @@ -1470,7 +1471,8 @@ void kvm_arch_irq_bypass_del_producer(struct 
 irq_bypass_consumer *cons,
struct kvm_kernel_irqfd *irqfd =
container_of(cons, struct kvm_kernel_irqfd, consumer);
  
 -  return;
 +  kvm_vgic_v4_unset_forwarding(irqfd->kvm, prod->irq,
 +   >irq_entry);
  }
  
  void kvm_arch_irq_bypass_stop(struct irq_bypass_consumer *cons)
 diff --git a/virt/kvm/arm/vgic/vgic-v4.c b/virt/kvm/arm/vgic/vgic-v4.c
 index c794f0cef09e..01a2889b7b7c 100644
 --- a/virt/kvm/arm/vgic/vgic-v4.c
 +++ b/virt/kvm/arm/vgic/vgic-v4.c
 @@ -18,6 +18,7 @@
  #include 
  #include 
  #include 
 +#include 
  
  #include "vgic.h"
  
 @@ -81,3 +82,110 @@ void vgic_v4_teardown(struct kvm *kvm)
its_vm->nr_vpes = 0;
its_vm->vpes = NULL;
  }
 +
 +static struct vgic_its *vgic_get_its(struct kvm *kvm,
 +   struct kvm_kernel_irq_routing_entry 
 *irq_entry)
 +{
 +  struct kvm_msi msi  = (struct kvm_msi) {
 +  .address_lo = irq_entry->msi.address_lo,
 +  .address_hi = irq_entry->msi.address_hi,
 +  .data   = irq_entry->msi.data,
 +  .flags  = irq_entry->msi.flags,
 +  .devid  = irq_entry->msi.devid,
 +  };
 +
 +  /*
 +   * Get a reference on the LPI. If NULL, this is not a valid
 +   * translation for any of our vITSs.
 +   */
>>> I don't understand the relevance of the above comment.
>>
>> Hmmm. The first part looks like an outdated leftover, as the ITS is not
>> refcounted, and we don't deal with LPIs here.
>>
> 
> I simply removed this comment.
> 
> [...]
> 
> I think the only thing left to fix on this patch is the IRQ_DISABLE_LAZY
> thing on its_map_vlpi() failures, which Marc can fix post -rc1.

Here's what I've queued on the irqchip side:

>From 9c0733704b99c89773416af3a412332b0e8bd2a4 Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Fri, 10 Nov 2017 09:00:41 +
Subject: [PATCH] irqchip/gic-v4: Clear IRQ_DISABLE_UNLAZY again if mapping
 fails

Should the call to irq_set_vcpu_affinity() fail at map time,
we should restore the normal lazy-disable behaviour instead
of staying with the eager disable that GICv4 requires.

Reported-by: Eric Auger 
Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-v4.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git 

Re: [PATCH 13/15] mm, devmap: introduce CONFIG_DEVMAP_MANAGED_PAGES

[Christoph Hellwig]

On Tue, Oct 31, 2017 at 04:22:46PM -0700, Dan Williams wrote:
> Combine the now three use cases of page-idle callbacks for ZONE_DEVICE
> memory into a common selectable symbol.

Very sparse changelog.  I understand the Kconfig bit, but it also seems to
introduce new static key functionality that isn't explained at all.

Re: [PATCH 0/2][v5] Add the ability to do BPF directed error injection

[David Miller]

From: Alexei Starovoitov 
Date: Wed, 8 Nov 2017 06:43:25 +0900

> looks great to me.
> Peter,
> could you please review x86 bits?

I'm still waiting for this.

Re: [PATCH RFC v3 6/7] proc: support new 'pids=all|ptraceable' mount option

[Djalal Harouni]

On Fri, Nov 10, 2017 at 3:38 AM, Andy Lutomirski  wrote:
> On Thu, Nov 9, 2017 at 8:14 AM, Djalal Harouni  wrote:
>> This patch introduces the new 'pids' mount option, as it was discussed
>> and suggested by Andy Lutomirski [1].
>>
>> * If 'pids=' is passed without 'newinstance' then it has no effect.
>
> Would it be safer this were an error instead?

Hm, I tend to say that you are right, but I also keep your comment
when you said that "newinstance" should be the default later and users
won't have to explicitly pass it. What you think ?

-- 
tixxdz

Re: [PATCH RFC v3 3/7] proc: add helpers to set and get proc hidepid and gid mount options

[Alexey Dobriyan]

On 11/9/17, Djalal Harouni  wrote:
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c

> -static bool has_pid_permissions(struct pid_namespace *pid,
> +static bool has_pid_permissions(struct proc_fs_info *fs_info,

More "const".

> diff --git a/fs/proc/inode.c b/fs/proc/inode.c
> index 9abc370..bdd808d 100644
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -476,11 +476,12 @@ struct inode *proc_get_inode(struct super_block *sb,
> struct proc_dir_entry *de)
>  int proc_fill_super(struct super_block *s, void *data, int silent)
>  {
>   struct proc_fs_info *fs_info = proc_sb(s);
> - struct pid_namespace *ns = get_pid_ns(fs_info->pid_ns);
>   struct inode *root_inode;
>   int ret;
>
> - if (!proc_parse_options(data, ns))
> + get_pid_ns(fs_info->pid_ns);
> +
> + if (!proc_parse_options(data, fs_info))
>   return -EINVAL;
>
>   /* User space would break if executables or devices appear on proc */
> diff --git a/fs/proc/internal.h b/fs/proc/internal.h
> index 4a67188..10bc7be 100644
> --- a/fs/proc/internal.h
> +++ b/fs/proc/internal.h
> @@ -240,7 +240,7 @@ static inline void proc_tty_init(void) {}
>   * root.c
>   */
>  extern struct proc_dir_entry proc_root;
> -extern int proc_parse_options(char *options, struct pid_namespace *pid);
> +extern int proc_parse_options(char *options, struct proc_fs_info
> *fs_info);

"extern" can be dropped if you're touching prototype anyway.



> +static inline int proc_fs_hide_pid(struct proc_fs_info *fs_info)
> +{
> + return fs_info->pid_ns->hide_pid;
> +}
> +
> +static inline kgid_t proc_fs_pid_gid(struct proc_fs_info *fs_info)
> +{
> + return fs_info->pid_ns->pid_gid;
> +}

More "const".

> @@ -59,6 +81,24 @@ static inline void proc_flush_task(struct task_struct
> *task)
>  {
>  }
>
> +static inline void proc_fs_set_hide_pid(struct proc_fs_info *fs_info, int
> hide_pid)
> +{
> +}
> +
> +static inline void proc_fs_set_pid_gid(struct proc_info_fs *fs_info, kgid_t
> gid)
> +{
> +}
> +
> +static inline int proc_fs_hide_pid(struct proc_fs_info *fs_info)
> +{
> + return 0;
> +}
> +
> +extern kgid_t proc_fs_pid_gid(struct proc_fs_info *fs_info)

ehh?

> +{
> + return GLOBAL_ROOT_GID;
> +}

Re: linux-next 20171018 to 20171108: reboot after 'freeing SMP alternatives memory'

[Pavel Machek]

On Fri 2017-11-10 00:04:07, Thomas Gleixner wrote:
> On Thu, 9 Nov 2017, Pavel Machek wrote:
> > Hi!
> > 
> > > > Machine is thinkpad x60; 32-bit intel.
> > > 
> > > On next-20171103: I get past kernel boot, but there's kernel panic
> > > (probably) while X is starting. (I can see the capslock led blinking.)
> > > 
> > > Any ideas?
> > 
> > With yesterday's git, it now hangs after "freeing SMP alternatives
> > memory".
> > 
> > Does it work for anyone on 32-bit Intel?
> 
> Yes, it does for me, but my test system is some arcane desktop box.

Ok, so I debugged some more, and it looks like I have two separate
problems:

1) Hang when the machine boots "hot". This has been there for long
long time, but the place of hang recently moved, which confused me.

2) next-20171103: I get past kernel boot, but there's kernel panic
(probably) while X is starting. (I can see the capslock led
blinking.). This still happens on next-20171110, if I boot the machine
"cold". This is new.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH v2 04/14] soundwire: Add MIPI DisCo property helpers

[Vinod Koul]

MIPI Discovery And Configuration (DisCo) Specification for SoundWire
specifies properties to be implemented for SoundWire Masters and
Slaves. The DisCo spec doesn't mandate these properties. However,
SDW bus cannot work without knowing these values.

The helper functions read the Master and Slave properties.
Implementers of Master or Slave drivers can use any of the below
three mechanisms:
   a) Use these APIs here as .read_prop() callback for Master
  and Slave
   b) Implement own methods and set those as .read_prop(), but invoke
  APIs in this file for generic read and override the values with
  platform specific data
   c) Implement ones own methods which do not use anything provided
  here

Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/Makefile |   2 +-
 drivers/soundwire/bus.c|   8 +
 drivers/soundwire/bus_type.c   |  18 ++
 drivers/soundwire/mipi_disco.c | 422 +
 include/linux/soundwire/sdw.h  | 284 +++
 5 files changed, 733 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soundwire/mipi_disco.c

diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
index c875e434f8b3..bcde0d26524c 100644
--- a/drivers/soundwire/Makefile
+++ b/drivers/soundwire/Makefile
@@ -3,5 +3,5 @@
 #
 
 #Bus Objs
-soundwire-bus-objs := bus_type.o bus.o slave.o
+soundwire-bus-objs := bus_type.o bus.o slave.o mipi_disco.o
 obj-$(CONFIG_SOUNDWIRE_BUS) += soundwire-bus.o
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 5bb9d930f86a..6cf4e5a7faea 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -75,6 +75,14 @@ int sdw_add_bus_master(struct sdw_bus *bus)
mutex_init(>bus_lock);
INIT_LIST_HEAD(>slaves);
 
+   if (bus->ops->read_prop) {
+   ret = bus->ops->read_prop(bus);
+   if (ret < 0) {
+   dev_err(bus->dev, "Bus read properties failed:%d", ret);
+   return ret;
+   }
+   }
+
/*
 * Enumeration device number and broadcast device number are
 * not used for assignment so mask these and other higher bits
diff --git a/drivers/soundwire/bus_type.c b/drivers/soundwire/bus_type.c
index 3e97a8284871..520d31562544 100644
--- a/drivers/soundwire/bus_type.c
+++ b/drivers/soundwire/bus_type.c
@@ -135,6 +135,8 @@ static int sdw_drv_probe(struct device *dev)
return ret;
}
 
+   slave->ops = drv->ops;
+
ret = drv->probe(slave, id);
if (ret) {
dev_err(dev, "Probe of %s failed: %d\n", drv->name, ret);
@@ -142,6 +144,22 @@ static int sdw_drv_probe(struct device *dev)
return ret;
}
 
+   /* device is probed so let's read the properties now */
+   if (slave->ops && slave->ops->read_prop)
+   slave->ops->read_prop(slave);
+
+   /*
+* Check for valid clk_stop_timeout, use DisCo worst case value of
+* 300ms
+*
+* TODO: check the timeouts and driver removal case
+*/
+   if (slave->prop.clk_stop_timeout == 0)
+   slave->prop.clk_stop_timeout = 300;
+
+   slave->bus->clk_stop_timeout = max_t(u32, slave->bus->clk_stop_timeout,
+   slave->prop.clk_stop_timeout);
+
return 0;
 }
 
diff --git a/drivers/soundwire/mipi_disco.c b/drivers/soundwire/mipi_disco.c
new file mode 100644
index ..7ade445068cd
--- /dev/null
+++ b/drivers/soundwire/mipi_disco.c
@@ -0,0 +1,422 @@
+/*
+ *  This file is provided under a dual BSD/GPLv2 license.  When using or
+ *  redistributing this file, you may do so under either license.
+ *
+ *  SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+ *
+ *  GPL LICENSE SUMMARY
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of version 2 of the GNU General Public License as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  

[PATCH v2 03/14] soundwire: Add Master registration

[Vinod Koul]

A Master registers with SoundWire bus and scans the firmware provided
for device description. In this patch we scan the ACPI namespaces and
create the SoundWire Slave devices based on the ACPI description

Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/Makefile|   2 +-
 drivers/soundwire/bus.c   | 163 +++
 drivers/soundwire/bus.h   |  20 +
 drivers/soundwire/slave.c | 172 ++
 include/linux/soundwire/sdw.h |  11 +++
 5 files changed, 367 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soundwire/bus.c
 create mode 100644 drivers/soundwire/slave.c

diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile
index d1281def7662..c875e434f8b3 100644
--- a/drivers/soundwire/Makefile
+++ b/drivers/soundwire/Makefile
@@ -3,5 +3,5 @@
 #
 
 #Bus Objs
-soundwire-bus-objs := bus_type.o
+soundwire-bus-objs := bus_type.o bus.o slave.o
 obj-$(CONFIG_SOUNDWIRE_BUS) += soundwire-bus.o
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
new file mode 100644
index ..5bb9d930f86a
--- /dev/null
+++ b/drivers/soundwire/bus.c
@@ -0,0 +1,163 @@
+/*
+ *  This file is provided under a dual BSD/GPLv2 license.  When using or
+ *  redistributing this file, you may do so under either license.
+ *
+ *  SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+ *
+ *  GPL LICENSE SUMMARY
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of version 2 of the GNU General Public License as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015-17 Intel Corporation.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Intel Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "bus.h"
+
+/**
+ * sdw_add_bus_master: add a bus Master instance
+ *
+ * @bus: bus instance
+ *
+ * Initializes the bus instance, read properties and create child
+ * devices.
+ */
+int sdw_add_bus_master(struct sdw_bus *bus)
+{
+   int ret;
+
+   if (!bus->dev) {
+   pr_err("SoundWire bus has no device");
+   return -ENODEV;
+   }
+
+   mutex_init(>bus_lock);
+   INIT_LIST_HEAD(>slaves);
+
+   /*
+* Enumeration device number and broadcast device number are
+* not used for assignment so mask these and other higher bits
+*/
+
+   /* Set higher order bits */
+   *bus->assigned = ~GENMASK(SDW_BROADCAST_DEV_NUM, SDW_ENUM_DEV_NUM);
+
+   /* Set device number and broadcast device number */
+   set_bit(SDW_ENUM_DEV_NUM, bus->assigned);
+   set_bit(SDW_BROADCAST_DEV_NUM, bus->assigned);
+
+   /*
+* SDW is an enumerable bus, but devices can be powered off. So,
+* they won't be able to report as present.
+*
+* Create Slave devices based on Slaves described in
+* the respective firmware (ACPI/DT)
+*/
+   if (IS_ENABLED(CONFIG_ACPI) && ACPI_HANDLE(bus->dev))
+   ret = sdw_acpi_find_slaves(bus);
+   else if 

[PATCH v2 06/14] soundwire: Add IO transfer

[Vinod Koul]

SoundWire bus supports read or write register(s) for SoundWire Slave
device. sdw_read() and sdw_write() APIs are provided for single
register read/write. sdw_nread() and sdw_nwrite() for operations on
contiguous registers.

Signed-off-by: Sanyog Kale 
Signed-off-by: Vinod Koul 
---
 drivers/soundwire/bus.c   | 278 ++
 drivers/soundwire/bus.h   |  38 ++
 include/linux/soundwire/sdw.h |  59 +
 3 files changed, 375 insertions(+)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 6cf4e5a7faea..70b60ba84592 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -72,6 +72,12 @@ int sdw_add_bus_master(struct sdw_bus *bus)
return -ENODEV;
}
 
+   if (!bus->ops) {
+   dev_err(bus->dev, "SoundWire Bus ops are not set");
+   return -EINVAL;
+   }
+
+   mutex_init(>msg_lock);
mutex_init(>bus_lock);
INIT_LIST_HEAD(>slaves);
 
@@ -141,6 +147,278 @@ void sdw_delete_bus_master(struct sdw_bus *bus)
 }
 EXPORT_SYMBOL(sdw_delete_bus_master);
 
+/*
+ * SDW IO Calls
+ */
+
+static inline int find_response_code(enum sdw_command_response resp)
+{
+   switch (resp) {
+   case SDW_CMD_OK:
+   return 0;
+
+   case SDW_CMD_IGNORED:
+   return -ENODATA;
+
+   case SDW_CMD_TIMEOUT:
+   return -ETIMEDOUT;
+
+   default:
+   return -EIO;
+   }
+}
+
+static inline int do_transfer(struct sdw_bus *bus, struct sdw_msg *msg)
+{
+   int retry = bus->prop.err_threshold;
+   enum sdw_command_response resp;
+   int ret = 0, i;
+
+   for (i = 0; i <= retry; i++) {
+   resp = bus->ops->xfer_msg(bus, msg);
+   ret = find_response_code(resp);
+
+   /* if cmd is ok or ignored return */
+   if (ret == 0 || ret == -ENODATA)
+   return ret;
+   }
+
+   return ret;
+}
+
+static inline int do_transfer_defer(struct sdw_bus *bus,
+   struct sdw_msg *msg, struct sdw_defer *defer)
+{
+   int retry = bus->prop.err_threshold;
+   enum sdw_command_response resp;
+   int ret = 0, i;
+
+   defer->msg = msg;
+   defer->length = msg->len;
+
+   for (i = 0; i <= retry; i++) {
+   resp = bus->ops->xfer_msg_defer(bus, msg, defer);
+   ret = find_response_code(resp);
+   /* if cmd is ok or ignored return */
+   if (ret == 0 || ret == -ENODATA)
+   return ret;
+   }
+
+   return ret;
+}
+
+static int sdw_reset_page(struct sdw_bus *bus, u16 dev_num)
+{
+   int retry = bus->prop.err_threshold;
+   enum sdw_command_response resp;
+   int ret = 0, i;
+
+   for (i = 0; i <= retry; i++) {
+   resp = bus->ops->reset_page_addr(bus, dev_num);
+   ret = find_response_code(resp);
+   /* if cmd is ok or ignored return */
+   if (ret == 0 || ret == -ENODATA)
+   return ret;
+   }
+
+   return ret;
+}
+
+/**
+ * sdw_transfer: Synchronous transfer message to a SDW Slave device
+ *
+ * @bus: SDW bus
+ * @slave: SDW Slave
+ * @msg: SDW message to be xfered
+ */
+int sdw_transfer(struct sdw_bus *bus,
+   struct sdw_slave *slave, struct sdw_msg *msg)
+{
+   int ret;
+
+   mutex_lock(>msg_lock);
+
+   ret = do_transfer(bus, msg);
+   if (ret != 0 && ret != -ENODATA)
+   dev_err(bus->dev, "trf on Slave %d failed:%d\n",
+   msg->dev_num, ret);
+
+   if (msg->page)
+   sdw_reset_page(bus, msg->dev_num);
+
+   mutex_unlock(>msg_lock);
+
+   return ret;
+}
+
+/**
+ * sdw_transfer_defer: Asynchronously transfer message to a SDW Slave device
+ *
+ * @bus: SDW bus
+ * @slave: SDW Slave
+ * @msg: SDW message to be xfered
+ * @defer: Defer block for signal completion
+ *
+ * Caller needs to hold the msg_lock lock while calling this
+ */
+int sdw_transfer_defer(struct sdw_bus *bus, struct sdw_slave *slave,
+   struct sdw_msg *msg, struct sdw_defer *defer)
+{
+   int ret;
+
+   if (!bus->ops->xfer_msg_defer)
+   return -ENOTSUPP;
+
+   ret = do_transfer_defer(bus, msg, defer);
+   if (ret != 0 && ret != -ENODATA)
+   dev_err(bus->dev, "Defer trf on Slave %d failed:%d\n",
+   msg->dev_num, ret);
+
+   if (msg->page)
+   sdw_reset_page(bus, msg->dev_num);
+
+   return ret;
+}
+
+
+int sdw_fill_msg(struct sdw_msg *msg, struct sdw_slave *slave,
+   u32 addr, size_t count, u16 dev_num, u8 flags, u8 *buf)
+{
+   msg->addr = addr;
+   msg->len = count;
+   msg->dev_num = dev_num;
+   msg->flags = flags;
+   msg->buf = buf;
+   msg->ssp_sync = false;
+   msg->page = false;
+
+   if (addr 

[PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[Dongjiu Geng]

If it is not RAS SError, directly inject virtual SError,
which will keep the old way. If it is RAS SError, firstly
let host ACPI module to handle it. For the ACPI handling,
if the error address is invalid, APEI driver will not
identify the address to hwpoison memory and can not notify
guest to do the recovery. In order to safe, KVM continues
categorizing errors and handle it separately.

If the RAS error is not propagated, let host user space to
handle it. The reason is that sometimes we can only kill the
guest effected application instead of panic whose guest OS.
Host user space specifies a valid ESR and inject virtual
SError, guest can just kill the current application if the
non-consumed error coming from guest application.

Signed-off-by: Dongjiu Geng 
Signed-off-by: Quanming Wu 
---
 arch/arm64/include/asm/esr.h | 15 
 arch/arm64/include/asm/kvm_asm.h |  3 ++
 arch/arm64/include/asm/system_misc.h |  1 +
 arch/arm64/kvm/handle_exit.c | 67 +---
 arch/arm64/mm/fault.c| 16 +
 5 files changed, 98 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 66ed8b6..aca7eee 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -102,6 +102,7 @@
 #define ESR_ELx_FSC_ACCESS (0x08)
 #define ESR_ELx_FSC_FAULT  (0x04)
 #define ESR_ELx_FSC_PERM   (0x0C)
+#define ESR_ELx_FSC_SERROR (0x11)
 
 /* ISS field definitions for Data Aborts */
 #define ESR_ELx_ISV_SHIFT  (24)
@@ -119,6 +120,20 @@
 #define ESR_ELx_CM_SHIFT   (8)
 #define ESR_ELx_CM (UL(1) << ESR_ELx_CM_SHIFT)
 
+/* ISS field definitions for SError interrupt */
+#define ESR_ELx_AET_SHIFT  (10)
+#define ESR_ELx_AET(UL(0x7) << ESR_ELx_AET_SHIFT)
+/* Uncontainable error */
+#define ESR_ELx_AET_UC (UL(0) << ESR_ELx_AET_SHIFT)
+/* Unrecoverable error */
+#define ESR_ELx_AET_UEU(UL(1) << ESR_ELx_AET_SHIFT)
+/* Restartable error */
+#define ESR_ELx_AET_UEO(UL(2) << ESR_ELx_AET_SHIFT)
+/* Recoverable error */
+#define ESR_ELx_AET_UER(UL(3) << ESR_ELx_AET_SHIFT)
+/* Corrected */
+#define ESR_ELx_AET_CE (UL(6) << ESR_ELx_AET_SHIFT)
+
 /* ISS field definitions for exceptions taken in to Hyp */
 #define ESR_ELx_CV (UL(1) << 24)
 #define ESR_ELx_COND_SHIFT (20)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 26a64d0..884f723 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -27,6 +27,9 @@
 #define ARM_EXCEPTION_IRQ0
 #define ARM_EXCEPTION_EL1_SERROR  1
 #define ARM_EXCEPTION_TRAP   2
+/* Error code for SError Interrupt (SEI) exception */
+#define KVM_SEI_SEV_RECOVERABLE  1
+
 /* The hyp-stub will return this for any kvm_call_hyp() call */
 #define ARM_EXCEPTION_HYP_GONE   HVC_STUB_ERR
 
diff --git a/arch/arm64/include/asm/system_misc.h 
b/arch/arm64/include/asm/system_misc.h
index 07aa8e3..9ee13ad 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, 
unsigned int,
 })
 
 int handle_guest_sea(phys_addr_t addr, unsigned int esr);
+int handle_guest_sei(void);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 7debb74..1afdc87 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CREATE_TRACE_POINTS
 #include "trace.h"
@@ -178,6 +179,66 @@ static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu 
*vcpu)
return arm_exit_handlers[hsr_ec];
 }
 
+/**
+ * kvm_handle_guest_sei - handles SError interrupt or asynchronous aborts
+ * @vcpu:  the VCPU pointer
+ *
+ * For RAS SError interrupt, firstly let host kernel handle it.
+ * If the AET is [ESR_ELx_AET_UER], then let user space handle it,
+ */
+static int kvm_handle_guest_sei(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+   unsigned int esr = kvm_vcpu_get_hsr(vcpu);
+   bool impdef_syndrome =  esr & ESR_ELx_ISV;  /* aka IDS */
+   unsigned int aet = esr & ESR_ELx_AET;
+
+   /*
+* This is not RAS SError
+*/
+   if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) {
+   kvm_inject_vabt(vcpu);
+   return 1;
+   }
+
+   /* The host kernel may handle this abort. */
+   handle_guest_sei();
+
+   /*
+* In below two conditions, it will directly inject the
+* virtual SError:
+* 1. The Syndrome is IMPLEMENTATION DEFINED
+* 2. It is Uncategorized SEI
+*/
+   if (impdef_syndrome ||
+   ((esr & ESR_ELx_FSC) != ESR_ELx_FSC_SERROR)) {
+   kvm_inject_vabt(vcpu);
+   return 1;
+   }

[PATCH net-next 2/2] net: dsa: lan9303: Clear offload_fwd_mark for IGMP

[Egil Hjelmeland]

Now that IGMP packets no longer is flooded in HW, we want the SW bridge to
forward packets based on bridge configuration. To make that happen,
IGMP packets must have skb->offload_fwd_mark = 0.

Signed-off-by: Egil Hjelmeland 
---
 net/dsa/tag_lan9303.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/net/dsa/tag_lan9303.c b/net/dsa/tag_lan9303.c
index 5ba01fc3c6ba..b8c5e52b2eff 100644
--- a/net/dsa/tag_lan9303.c
+++ b/net/dsa/tag_lan9303.c
@@ -92,6 +92,8 @@ static struct sk_buff *lan9303_rcv(struct sk_buff *skb, 
struct net_device *dev,
 {
u16 *lan9303_tag;
unsigned int source_port;
+   u16 ether_type_nw;
+   u8 ip_protocol;
 
if (unlikely(!pskb_may_pull(skb, LAN9303_TAG_LEN))) {
dev_warn_ratelimited(>dev,
@@ -129,6 +131,17 @@ static struct sk_buff *lan9303_rcv(struct sk_buff *skb, 
struct net_device *dev,
skb->offload_fwd_mark = !ether_addr_equal(skb->data - ETH_HLEN,
  eth_stp_addr);
 
+   /* We also need IGMP packets to have skb->offload_fwd_mark = 0.
+* Solving this for all conceivable situations would add more cost to
+* every packet. Instead we handle just the common case:
+* No VLAN tag + Ethernet II framing.
+* Test least probable term first.
+*/
+   ether_type_nw = lan9303_tag[2];
+   ip_protocol = *(skb->data + 9);
+   if (ip_protocol == IPPROTO_IGMP && ether_type_nw == htons(ETH_P_IP))
+   skb->offload_fwd_mark = 0;
+
return skb;
 }
 
-- 
2.11.0

[PATCH net-next 0/2] net: dsa: lan9303: IGMP handling

[Egil Hjelmeland]

Set up the HW switch to trap IGMP packets to CPU port. 
And make sure skb->offload_fwd_mark is cleared for incoming IGMP packets.

skb->offload_fwd_mark calculation is a candidate for consolidation into the
DSA core. The calculation can probably be more polished when done at a point
where DSA has updated skb.  


Egil Hjelmeland (2):
  net: dsa: lan9303: Set up trapping of IGMP to CPU port
  net: dsa: lan9303: Clear offload_fwd_mark for IGMP

 drivers/net/dsa/lan9303-core.c | 26 ++
 net/dsa/tag_lan9303.c  | 13 +
 2 files changed, 39 insertions(+)

-- 
2.11.0

[PATCH net-next 1/2] net: dsa: lan9303: Set up trapping of IGMP to CPU port

[Egil Hjelmeland]

IGMP packets should be trapped to the CPU port. The SW bridge knows
whether to forward to other ports.

With "IGMP snooping for local traffic" merged, IGMP trapping is also
required for stable IGMPv2 operation.

LAN9303 does not trap IGMP packets by default.

Enable IGMP trapping in lan9303_setup.

Signed-off-by: Egil Hjelmeland 
---
 drivers/net/dsa/lan9303-core.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 320651a57c6f..6d7dee67d822 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -153,6 +153,8 @@
 # define LAN9303_SWE_VLAN_UNTAG_PORT0 BIT(12)
 #define LAN9303_SWE_VLAN_CMD_STS 0x1810
 #define LAN9303_SWE_GLB_INGRESS_CFG 0x1840
+# define LAN9303_SWE_GLB_INGR_IGMP_TRAP BIT(7)
+# define LAN9303_SWE_GLB_INGR_IGMP_PORT(p) BIT(10 + p)
 #define LAN9303_SWE_PORT_STATE 0x1843
 # define LAN9303_SWE_PORT_STATE_FORWARDING_PORT2 (0)
 # define LAN9303_SWE_PORT_STATE_LEARNING_PORT2 BIT(5)
@@ -450,6 +452,21 @@ static int lan9303_read_switch_reg(struct lan9303 *chip, 
u16 regnum, u32 *val)
return ret;
 }
 
+static int lan9303_write_switch_reg_mask(struct lan9303 *chip, u16 regnum,
+u32 val, u32 mask)
+{
+   int ret;
+   u32 reg;
+
+   ret = lan9303_read_switch_reg(chip, regnum, );
+   if (ret)
+   return ret;
+
+   reg = (reg & ~mask) | val;
+
+   return lan9303_write_switch_reg(chip, regnum, reg);
+}
+
 static int lan9303_write_switch_port(struct lan9303 *chip, int port,
 u16 regnum, u32 val)
 {
@@ -905,6 +922,15 @@ static int lan9303_setup(struct dsa_switch *ds)
if (ret)
dev_err(chip->dev, "failed to re-enable switching %d\n", ret);
 
+   /* Trap IGMP to port 0 */
+   ret = lan9303_write_switch_reg_mask(chip, LAN9303_SWE_GLB_INGRESS_CFG,
+   LAN9303_SWE_GLB_INGR_IGMP_TRAP |
+   LAN9303_SWE_GLB_INGR_IGMP_PORT(0),
+   LAN9303_SWE_GLB_INGR_IGMP_PORT(1) |
+   LAN9303_SWE_GLB_INGR_IGMP_PORT(2));
+   if (ret)
+   dev_err(chip->dev, "failed to setup IGMP trap %d\n", ret);
+
return 0;
 }
 
-- 
2.11.0

Re: [PATCH 20/30] x86, mm: remove hard-coded ASID limit checks

[Peter Zijlstra]

On Wed, Nov 08, 2017 at 11:47:24AM -0800, Dave Hansen wrote:
> +#define CR3_HW_ASID_BITS 12
> +#define NR_AVAIL_ASIDS ((1< - VM_WARN_ON_ONCE(asid > 4094);
> + VM_WARN_ON_ONCE(asid > NR_AVAIL_ASIDS);

Not the same number

Re: [PATCH v1 0/2] DRM driver for ILI9225 display panels

[Noralf Trønnes]

Hi David, nice to see a new driver.

Den 08.11.2017 04.52, skrev David Lechner:

This is a new driver for ILI9225 based display panels.

There are a couple of things that stand out:

1.  Despite my best efforts, I could not find a name for this display[1], so I
 have made up a generic name for it. If someone recognizes this and has a
 name for it, please speak up. The best documentation I could find was
 here[2].

2.  There is quite a bit of one-off code copied from mipi-dbi.c. Based on the
 feedback from a previous patch series, I'm guessing that we don't want to
 modify mipi-dbi.c to accommodate the ILI9225 controller because the ILI9225
 controller does not use standard MIPI commands. ILI9225 has it's own
 non-standard command set, but other than that, it pretty much matches the
 generic mipi-dbi driver in all regards.


Yes you're right, I don't want non MIPI code in mipi-dbi, but we can
try and make it flexible for usage with DBI like interfaces.


 Code that could be easily shared:

 a.  ili9225_buf_copy() is exactly the same as mipi_dbi_buf_copy()
 - ili9225_buf_copy() is used in ili9225_fb_dirty()
 - mipi_dbi_buf_copy() is static in mipi-dbi.c


You can export mipi_dbi_buf_copy().


 b.  ili9225_spi_cmd_max_speed() is exactly the same as
 mipi_dbi_spi_cmd_max_speed()
 - ili9225_spi_cmd_max_speed() is used in ili9225_command() below, so
   would not need to be copied if mipi_dbi_typec3_command() could be
   shared
 - mipi_dbi_spi_cmd_max_speed() is static in mipi-dbi.c


Same here, you can export the function.


 c.  ili9225_command() is nearly the same as mipi_dbi_typec3_command()
 - a few unused lines were removed so I didn't have to copy even more
   code, but these would not be an issue if code was shared
 - cmd == ILI9225_WRITE_DATA_TO_GRAM instead of
   cmd == MIPI_DCS_WRITE_MEMORY_START

 d.  ili9225_spi_init() is nearly the same as mipi_dbi_spi_init()
 - a few unused lines were removed so I didn't have to copy even more
   code, but these would not be an issue if code was shared
 - mipi->command = ili9225_command instead of
   mipi->command = mipi_dbi_typec3_command
 - this function would not need to be copied if 
mipi_dbi_typec3_command()
   was modified to work with the ILI9225 command set too


Looks like you can use mipi_dbi_spi_init() and reassign afterwards:
    mipi_dbi_spi_init();
    mipi->command = ili9225_command;


 e.  ili9225_init() is nearly the same as mipi_dbi_init()
 - only difference is ili9225_fb_funcs instead of mipi_dbi_fb_funcs


When we get framebuffer flushing trough atomic modeset, we'll use a generic
fb_dirty and at that point it will be possible to use mipi_dbi_init().
The actual flushing will happen in the update callback I guess.


3.  I haven't tried it, but I believe that it is possible to implement
 DRM_FORMAT_RGB888 directly instead of simulating DRM_FORMAT_XRGB.
 I don't know if there would be any real benefit to doing this. I am not
 familiar enough with userspace programs/libraries to know if this mode is
 universally used. And, it will only physically be 18-bit color instead of
 24-bit but will increase the amount of data transferred by 50% (3 bytes per
 pixel instead of 2). Implementing this would have a side effect of making
 the one-off shared code (described above) more than one-off though.


I have tried it on a display and I couldn't really tell the difference
between 16-bit and 18-bit colors, with X windows at least. And as you
say it's terrible for the framerate.

I'll look closer through the driver later today and see if I have more
comments.

Side note:
This controller can also do something called 24-bit 4 wire SPI. It uses a
Start byte the same way that the (only) SPI mode on ILI9320 and ILI9325 do.
I did a test implementation for ILI9325 where I used regmap as the register
abstraction: https://github.com/notro/tinydrm/blob/master/tinydrm-ili9325.c

Noralf.


[1]: https://github.com/Nkawu/TFT_22_ILI9225
[2]: http://www.hotmcu.com/22-176x220-tft-lcd-with-spi-interface-p-316.html

David Lechner (2):
   dt-bindings: Add binding for Ilitek ILI9225 display panels
   drm/tinydrm: add driver for ILI9225 panels

  .../devicetree/bindings/display/ilitek,ili9225.txt |  25 +
  MAINTAINERS|   6 +
  drivers/gpu/drm/tinydrm/Kconfig|  10 +
  drivers/gpu/drm/tinydrm/Makefile   |   1 +
  drivers/gpu/drm/tinydrm/ili9225.c  | 547 +
  5 files changed, 589 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/ilitek,ili9225.txt
  create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

--
2.7.4

[PATCH 1/4] ASN.1: Adjust two function calls together with a variable assignment

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 10 Nov 2017 10:40:17 +0100

The script "checkpatch.pl" pointed information out like the following.

ERROR: do not use assignment in if condition

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 
---
 scripts/asn1_compiler.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/asn1_compiler.c b/scripts/asn1_compiler.c
index c1b7ef3e24c1..e37e5ef3fabb 100644
--- a/scripts/asn1_compiler.c
+++ b/scripts/asn1_compiler.c
@@ -606,12 +606,14 @@ int main(int argc, char **argv)
exit(1);
}
 
-   if (!(buffer = malloc(st.st_size + 1))) {
+   buffer = malloc(st.st_size + 1);
+   if (!buffer) {
perror(NULL);
exit(1);
}
 
-   if ((readlen = read(fd, buffer, st.st_size)) < 0) {
+   readlen = read(fd, buffer, st.st_size);
+   if (readlen < 0) {
perror(filename);
exit(1);
}
-- 
2.15.0

Re: [PATCH 3/4] x86/boot/compressed/64: Introduce place_trampoline()

[Ingo Molnar]

* Kirill A. Shutemov  wrote:

> > One other detail I noticed:
> > 
> > /* Bound size of trampoline code */
> > .orglvl5_trampoline_src + LVL5_TRAMPOLINE_CODE_SIZE
> > 
> > will this generate a build error if the trampoline code exceeds 0x40?
> 
> Yes, this is the point. Just a failsafe if trampoline code would grew too
> much.

Ok, good!

Thanks,

Ingo

Re: [PATCH 08/30] x86, kaiser: unmap kernel from userspace page tables (core patch)

[Ingo Molnar]

* Dave Hansen  wrote:

> From: Dave Hansen 
> 
> These patches are based on work from a team at Graz University of
> Technology: https://github.com/IAIK/KAISER .  This work would not have
> been possible without their work as a starting point.

> Note: The original KAISER authors signed-off on their patch.  Some of
> their code has been broken out into other patches in this series, but
> their SoB was only retained here.
> 
> Signed-off-by: Richard Fellner 
> Signed-off-by: Moritz Lipp 
> Signed-off-by: Daniel Gruss 
> Signed-off-by: Michael Schwarz 
> Signed-off-by: Dave Hansen 

That's not how SOB chains should be used normally - nor does the current code 
have 
much resemblance to the original code.

So you credit them in the file:

> --- /dev/null 2017-11-06 07:51:38.702108459 -0800
> +++ b/arch/x86/mm/kaiser.c2017-11-08 10:45:29.893681394 -0800
> @@ -0,0 +1,412 @@
> +/*
> + * Copyright(c) 2017 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * Based on work published here: https://github.com/IAIK/KAISER
> + * Modified by Dave Hansen 
 *   Signed-off-by: Moritz Lipp 
 *   Signed-off-by: Daniel Gruss 
 *   Signed-off-by: Michael Schwarz 
 *
 * At:
 *
 *   https://github.com/IAIK/KAISER
 */

Or something like that - but the original SOBs should not be carried over as-is 
into the commit log entry.

Thanks,

Ingo

Re: [PATCH] ovl: fix null pointer dereference on ofs allocation failure.

[Miklos Szeredi]

On Thu, Nov 9, 2017 at 6:47 PM, Colin King  wrote:
> From: Colin Ian King 
>
> The current error exit path when ofs fails to allocate jumps
> to clean-up code that calls ovl_free_fs resulting in a null pointer
> dereference on the null ovl pointer.  Fix this by simply returning
> with the -ENOMEM status in err.
>
> Detected by CoverityScan, CID#1461284 ("Dereference after null check")


Thanks, fixed.

Miklos

Re: [PATCH 12/15] mm, dax: enable filesystems to trigger page-idle callbacks

[Christoph Hellwig]

> +DEFINE_MUTEX(devmap_lock);

static?

> +#if IS_ENABLED(CONFIG_FS_DAX)
> +static void generic_dax_pagefree(struct page *page, void *data)
> +{
> +}
> +
> +struct dax_device *fs_dax_claim_bdev(struct block_device *bdev, void *owner)
> +{
> + struct dax_device *dax_dev;
> + struct dev_pagemap *pgmap;
> +
> + if (!blk_queue_dax(bdev->bd_queue))
> + return NULL;
> + dax_dev = fs_dax_get_by_host(bdev->bd_disk->disk_name);
> + if (!dax_dev->pgmap)
> + return dax_dev;
> + pgmap = dax_dev->pgmap;

> + mutex_lock(_lock);
> + if ((pgmap->data && pgmap->data != owner) || pgmap->page_free
> + || pgmap->page_fault
> + || pgmap->type != MEMORY_DEVICE_HOST) {
> + put_dax(dax_dev);
> + mutex_unlock(_lock);
> + return NULL;
> + }
> +
> + pgmap->type = MEMORY_DEVICE_FS_DAX;
> + pgmap->page_free = generic_dax_pagefree;
> + pgmap->data = owner;
> + mutex_unlock(_lock);

All this deep magic will need some explanation.  So far I don't understand
it at all, but maybe the later patches will help..

Re: [PATCH 3/4] x86/boot/compressed/64: Introduce place_trampoline()

[Ingo Molnar]

* Kirill A. Shutemov  wrote:

> If bootloader enables 64-bit mode with 4-level paging, we need to
> switch over to 5-level paging. The switching requires disabling paging.
> It works fine if kernel itself is loaded below 4G.
> 
> If bootloader put the kernel above 4G (not sure if anybody does this),
> we would loose control as soon as paging is disabled as code becomes
> unreachable.
> 
> To handle the situation, we need a trampoline in lower memory that would
> take care about switching on 5-level paging.
> 
> Apart from trampoline itself we also need place to store top level page
> table in lower memory as we don't have a way to load 64-bit value into
> CR3 from 32-bit mode. We only really need 8-bytes there as we only use
> the very first entry of the page table. But we allocate whole page
> anyway. We cannot have the code in the same because, there's hazard that
> a CPU would read page table speculatively and get confused seeing
> garbage.
> 
> This patch introduces place_trampoline() that finds right spot in lower
> memory for trampoline, copies trampoline code there and setups new top
> level page table for 5-level paging.
> 
> At this point we do all the preparation, but not yet use trampoline.
> It will be done in following patch.
> 
> Signed-off-by: Kirill A. Shutemov 
> ---
>  arch/x86/boot/compressed/head_64.S   | 13 +++
>  arch/x86/boot/compressed/pagetable.c | 42 
> 
>  arch/x86/boot/compressed/pagetable.h | 18 
>  3 files changed, 73 insertions(+)
>  create mode 100644 arch/x86/boot/compressed/pagetable.h
> 
> diff --git a/arch/x86/boot/compressed/head_64.S 
> b/arch/x86/boot/compressed/head_64.S
> index 6ac8239af2b6..4d1555b39de0 100644
> --- a/arch/x86/boot/compressed/head_64.S
> +++ b/arch/x86/boot/compressed/head_64.S
> @@ -315,6 +315,18 @@ ENTRY(startup_64)
>* The first step is go into compatibility mode.
>*/
>  
> + /*
> +  * Find suitable place for trampoline and populate it.
> +  * The address will be stored in RCX.
> +  *
> +  * RSI holds real mode data and need to be preserved across
> +  * a function call.
> +  */
> + pushq   %rsi
> + callplace_trampoline
> + popq%rsi
> + movq%rax, %rcx
> +
>   /* Clear additional page table */
>   leaqlvl5_pgtable(%rbx), %rdi
>   xorq%rax, %rax

One request: it's always going to be fragile if the _only_ thing that uses the 
trampoline is the 5-level paging code.

Could we use the trampoline in the 4-level paging case too? It's not required, 
but 
would test much of the trampoline allocation and copying machinery - and the 
performance cost is negligible.

Thanks,

Ingo

Re: [PATCH 3/4] x86/boot/compressed/64: Introduce place_trampoline()

[Ingo Molnar]

* Kirill A. Shutemov  wrote:

> --- a/arch/x86/boot/compressed/head_64.S
> +++ b/arch/x86/boot/compressed/head_64.S
> @@ -315,6 +315,18 @@ ENTRY(startup_64)
>* The first step is go into compatibility mode.
>*/
>  
> + /*
> +  * Find suitable place for trampoline and populate it.
> +  * The address will be stored in RCX.
> +  *
> +  * RSI holds real mode data and need to be preserved across
> +  * a function call.
> +  */
> + pushq   %rsi
> + callplace_trampoline
> + popq%rsi
> + movq%rax, %rcx
> +
>   /* Clear additional page table */
>   leaqlvl5_pgtable(%rbx), %rdi
>   xorq%rax, %rax

So in the final version of this code we now have:

pushq   %rsi
callneed_to_enabled_l5
popq%rsi

/* If need_to_enabled_l5() returned zero, we're done here. */
cmpq$0, %rax
je  lvl5

/*
 * At this point we are in long mode with 4-level paging enabled,
 * but we want to enable 5-level paging.
 *
 * The problem is that we cannot do it directly. Setting LA57 in
 * long mode would trigger #GP. So we need to switch off long mode
 * first.
 *
 * We use trampoline in lower memory to handle situation when
 * bootloader put the kernel image above 4G.
 *
 * The first step is go into compatibility mode.
 */

/*
 * Find suitable place for trampoline and populate it.
 * The address will be stored in RCX.
 *
 * RSI holds real mode data and need to be preserved across
 * a function call.
 */
pushq   %rsi
callplace_trampoline
popq%rsi
movq%rax, %rcx

Firstly, the 'need_to_enabled_l5' name sucks because it includes a typo, but 
also 
because the prefix is way too generic.

Something like:

l5_paging_required()

would read a lot better - and would also provide a namespace for all L5 paging 
related functions.

Secondly, couldn't this be combined into a single .c function, named 
accordingly:

l5_paging_prepare()

which would return true if L5 paging is available and should be enabled. In 
this 
case the trampoline copying function would be called in C, by 
l5_paging_prepare().

This further reduces the amount of assembly code.

Thanks,

Ingo

Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

[WANG Chao]

On 11/10/17 at 08:25P, Ingo Molnar wrote:
> 
> * Rafael J. Wysocki  wrote:
> 
> > Hi Linus,
> > 
> > On 11/9/2017 11:38 AM, WANG Chao wrote:
> > > Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
> > > a serious performance issue when reading from /proc/cpuinfo on system
> > > with aperfmperf.
> > > 
> > > For each cpu, arch_freq_get_on_cpu() sleeps 20ms to get its frequency.
> > > On a system with 64 cpus, it takes 1.5s to finish running `cat
> > > /proc/cpuinfo`, while it previously was done in 15ms.
> > 
> > Honestly, I'm not sure what to do to address this ATM.
> > 
> > The last requested frequency is only available in the non-HWP case, so it
> > cannot be used universally.
> 
> This is a serious regression that needs to be fixed ASAP, because the 
> slowdown is 
> utterly ridiculous on a 120 CPU system:
> 
>   fomalhaut:~> time cat /proc/cpuinfo  >/dev/null
> 
>   real0m2.689s
>   user0m0.001s
>   sys 0m0.007s

Because 4.14 is about to release, how about adding this patch to 4.14
now? We can work on a more sophisticated solution later.

Thanks,
WANG Chao

Re: [PATCH 2/3] perf tools: Fix build for hardened environments

[Jiri Olsa]

On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu:
> > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> > > > From: Jiri Olsa 
> > > > 
> > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > > hardened specs from redhat-rpm-config package. We apply them only
> > > > for perl/python objects, which makes them not compatible with the
> > > > rest of the objects and the build fails with:
> > > > 
> > > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against 
> > > > `.rodata.str1.1' can not be used when making a shared object; recompile 
> > > > with -fPIC
> > > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > > > `.text' can not be used when making a shared object; recompile with 
> > > > -fPIC
> > > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > > >   collect2: error: ld returned 1 exit status
> > > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > > >   make: *** [Makefile:69: all] Error 2
> > > > 
> > > > Mainly it's caused by perl/python objects being compiled with:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > > 
> > > > which prevent the final link impossible, because it will check
> > > > for 'proper' objects with following option:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > > 
> > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options
> > > > for all the objects.
> > > 
> > > Humm, so we're basically using the hardened config only we build with
> > > PERL or PYTHON, should we use that always, i.e. ask the distro what set
> > > of flags we should use?
> > 
> > right, I think this needs to be detected like we do for features,
> > since there maybe some supported gcc versions to detect
> 
> Right, since we want to honour what the distro makers decided was the
> best set for them, and to be able to link with other libraries, etc.
> 
> But then I think this should be done more explicitely, right? Do you
> envision some way to do that without having to try to build perl or
> python, that may not be installed, etc?
> 

I'll check on it.. I think we could use feature detection and
enable that by default and add NO_HARDENED_BUILD variable as
we do for features.. and detect that python/perl or whatever
else is using that and warn

> Of course users wanting to use something different may just set CFLAGS
> and be done with it, in which case I think this should also affect the
> perl and python CFLAGS, removing that distro specific stuff since the
> user is changing something different.

yep

jirka

Re: [PATCH 3/4] x86/boot/compressed/64: Introduce place_trampoline()

[Kirill A. Shutemov]

On Fri, Nov 10, 2017 at 10:14:53AM +0100, Ingo Molnar wrote:
> I'm wondering, how did you test it if no current bootloader puts the kernel 
> to 
> above addresses of 4G?

I didn't test it directly.

I've checked with debugger that there's no memory accesses above 1M
between disabling paging in the trampoline and returning back from
trampoline to the main kernel image code.

-- 
 Kirill A. Shutemov

[PATCH] x86/acpi: Fix improper handling of SCI INT for platforms supporting only IOAPIC mode

[Vikas C Sajjan]

The platforms which support only IOAPIC mode and whose SCI INT is
greater than 16, passes SCI INT via FADT and not via MADT int src override
structure. In such cases current logic fails to handle it and throws error
"Invalid bus_irq %u for legacy override". This patch handles the above
 mentioned case. While at it, also modify function mp_override_legacy_irq()
to use the newly introduced function mp_register_ioapic_irq().

Signed-off-by: Vikas C Sajjan 
Signed-off-by: Sunil V L 
Signed-off-by: Abdul Lateef Attar 
---
 arch/x86/kernel/acpi/boot.c | 77 +++--
 1 file changed, 47 insertions(+), 30 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 079535e..8ab97a5 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -342,13 +342,12 @@ static int acpi_register_lapic(int id, u32 acpiid, u8 
enabled)
 #ifdef CONFIG_X86_IO_APIC
 #define MP_ISA_BUS 0
 
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+   u8 trigger, u32 gsi);
+
 static void __init mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger,
  u32 gsi)
 {
-   int ioapic;
-   int pin;
-   struct mpc_intsrc mp_irq;
-
/*
 * Check bus_irq boundary.
 */
@@ -357,32 +356,8 @@ static void __init mp_override_legacy_irq(u8 bus_irq, u8 
polarity, u8 trigger,
return;
}
 
-   /*
-* Convert 'gsi' to 'ioapic.pin'.
-*/
-   ioapic = mp_find_ioapic(gsi);
-   if (ioapic < 0)
+   if (mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi) < 0)
return;
-   pin = mp_find_ioapic_pin(ioapic, gsi);
-
-   /*
-* TBD: This check is for faulty timer entries, where the override
-*  erroneously sets the trigger to level, resulting in a HUGE
-*  increase of timer interrupts!
-*/
-   if ((bus_irq == 0) && (trigger == 3))
-   trigger = 1;
-
-   mp_irq.type = MP_INTSRC;
-   mp_irq.irqtype = mp_INT;
-   mp_irq.irqflag = (trigger << 2) | polarity;
-   mp_irq.srcbus = MP_ISA_BUS;
-   mp_irq.srcbusirq = bus_irq; /* IRQ */
-   mp_irq.dstapic = mpc_ioapic_id(ioapic); /* APIC ID */
-   mp_irq.dstirq = pin;/* INTIN# */
-
-   mp_save_irq(_irq);
-
/*
 * Reset default identity mapping if gsi is also an legacy IRQ,
 * otherwise there will be more than one entry with the same GSI
@@ -429,6 +404,44 @@ static int mp_config_acpi_gsi(struct device *dev, u32 gsi, 
int trigger,
return 0;
 }
 
+static int __init mp_register_ioapic_irq(u8 bus_irq, u8 polarity,
+   u8 trigger, u32 gsi)
+{
+   int ioapic;
+   int pin;
+   struct mpc_intsrc mp_irq;
+
+   /*
+* Convert 'gsi' to 'ioapic.pin'.
+*/
+   ioapic = mp_find_ioapic(gsi);
+   if (ioapic < 0) {
+   pr_warn("Failed to find ioapic for gsi : %u\n", gsi);
+   return ioapic;
+   }
+   pin = mp_find_ioapic_pin(ioapic, gsi);
+
+   /*
+* TBD: This check is for faulty timer entries, where the override
+*  erroneously sets the trigger to level, resulting in a HUGE
+*  increase of timer interrupts!
+*/
+   if ((bus_irq == 0) && (trigger == 3))
+   trigger = 1;
+
+   mp_irq.type = MP_INTSRC;
+   mp_irq.irqtype = mp_INT;
+   mp_irq.irqflag = (trigger << 2) | polarity;
+   mp_irq.srcbus = MP_ISA_BUS;
+   mp_irq.srcbusirq = bus_irq; /* IRQ */
+   mp_irq.dstapic = mpc_ioapic_id(ioapic); /* APIC ID */
+   mp_irq.dstirq = pin;/* INTIN# */
+
+   mp_save_irq(_irq);
+
+   return 0;
+}
+
 static int __init
 acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long 
end)
 {
@@ -473,7 +486,11 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 
polarity, u16 trigger,
if (acpi_sci_flags & ACPI_MADT_POLARITY_MASK)
polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
 
-   mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+   if (bus_irq < NR_IRQS_LEGACY)
+   mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+   else
+   mp_register_ioapic_irq(bus_irq, polarity, trigger, gsi);
+
acpi_penalize_sci_irq(bus_irq, trigger, polarity);
 
/*
-- 
1.9.1

Re: [PATCH 1/3] HID: cp2112: fix interface specification URL

[Jiri Kosina]

On Fri, 10 Nov 2017, Sébastien Szymanski wrote:

> >> Signed-off-by: Sébastien Szymanski 
> >> ---
> >>  drivers/hid/hid-cp2112.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> >> index 078026f..28e3c18 100644
> >> --- a/drivers/hid/hid-cp2112.c
> >> +++ b/drivers/hid/hid-cp2112.c
> >> @@ -21,7 +21,7 @@
> >>   * Data Sheet:
> >>   *   http://www.silabs.com/Support%20Documents/TechnicalDocs/CP2112.pdf
> >>   * Programming Interface Specification:
> >> - *   http://www.silabs.com/Support%20Documents/TechnicalDocs/AN495.pdf
> >> + *   
> >> https://www.silabs.com/documents/public/application-notes/an495-cp2112-interface-specification.pdf
> >>   */
> > 
> > I've applied patches 1 and 2 (with stable anotation) for now. Thanks,
> > 
> 
> Thanks, I've send a v2 of patch 3.
> 
> Regards,
> 
> P.S: I don't see patch 1 on your cgit, is it normal?

It's been applied only locally, today I've actually pushed it out. Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041

[James Morse]

Hi Shanker,

On 09/11/17 15:22, Shanker Donthineni wrote:
> On 11/09/2017 05:08 AM, James Morse wrote:
>> On 04/11/17 21:43, Shanker Donthineni wrote:
>>> On 11/03/2017 10:11 AM, Robin Murphy wrote:
 On 03/11/17 03:27, Shanker Donthineni wrote:
> The ARM architecture defines the memory locations that are permitted
> to be accessed as the result of a speculative instruction fetch from
> an exception level for which all stages of translation are disabled.
> Specifically, the core is permitted to speculatively fetch from the
> 4KB region containing the current program counter and next 4KB.
>
> When translation is changed from enabled to disabled for the running
> exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
> Falkor core may errantly speculatively access memory locations outside
> of the 4KB region permitted by the architecture. The errant memory
> access may lead to one of the following unexpected behaviors.
>
> 1) A System Error Interrupt (SEI) being raised by the Falkor core due
>to the errant memory access attempting to access a region of memory
>that is protected by a slave-side memory protection unit.
> 2) Unpredictable device behavior due to a speculative read from device
>memory. This behavior may only occur if the instruction cache is
>disabled prior to or coincident with translation being changed from
>enabled to disabled.
>
> To avoid the errant behavior, software must execute an ISB immediately
> prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.

> diff --git a/arch/arm64/include/asm/assembler.h 
> b/arch/arm64/include/asm/assembler.h
> index b6dfb4f..4c91efb 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -514,6 +515,22 @@
>   *   reg: the value to be written.
>   */
>   .macro  write_sctlr, eln, reg
> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
> + tbnz\reg, #0, 8000f  // enable MMU?
>>
>> Won't this match any change that leaves the MMU enabled?
> 
> Yes. No need to apply workaround if the MMU is going to be enabled.

(Sorry, looks like I had this upside down)

My badly-made-point is you can't know if the MMU is being disabled unless you
have both the old and new values.

As an example, in el2_setup, (where the MMU is disabled), we set the EE/E0E bits
to match the kernel's endianness. Won't your macro will insert an unnecessary
isb? Is this needed for the errata workaround?


>> I think the macro is making this more confusing. Disabling the MMU is obvious
>> from the call-site, (and really rare!). Trying to work it out from a macro 
>> makes
>> it more complicated than necessary.

> Not clear, are you suggesting not to use read{write}_sctlr() macros instead 
> apply 
> the workaround from the call-site based on the MMU-on status?

Yes. This is the only way to patch only the locations that turn the MMU off.


> If yes, It simplifies
> the code logic but CONFIG_QCOM_FALKOR_ERRATUM_1041 references are scatter 
> everywhere. 

Wouldn't they only appear in the places that are affected by the errata?
This is exactly what we want, anyone touching that code now knows they need to
double check this behaviour, (and ask you to test it!).

Otherwise we have a macro second guessing what is happening, if its not quite
right (because some information has been lost), we're now not sure what we need
to do if we ever refactor any of this code.

[...]

>>> I'll prefer alternatives
>>> just to avoid the unnecessary overhead on future Qualcomm Datacenter
>>> server CPUs and regression on other CPUs because of inserting an ISB
>>
>> I think hiding errata on other CPUs is a good argument.
>>
>> My suggestion would be:
>>> #ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
>>> isb
>>> #endif
>>
>> In head.S and efi-entry.S, as these run before alternatives.
>> Then use alternatives to add just the isb in the mmu-off path for the other 
>> callers.

> Thanks for your opinion on this one, I'll change to an unconditional ISB in 
> v2 patch.
> After this change the enable_mmu() issues two ISBs before writing to 
> SCTLR_EL1.

Another great reason not to wrap this in a macro, there may already be a
suitable isb, in which case a comment will suffice.


> Are you okay with this behavior?

Back-to-back isb doesn't sound like a good idea.


>  ENTRY(__enable_mmu)
> mrs x1, ID_AA64MMFR0_EL1
> ubfxx2, x1, #ID_AA64MMFR0_TGRAN_SHIFT, 4
> cmp x2, #ID_AA64MMFR0_TGRAN_SUPPORTED
> b.ne__no_granule_support
> update_early_cpu_boot_status 0, x1, x2
> adrpx1, idmap_pg_dir
> adrpx2, swapper_pg_dir
> msr ttbr0_el1, x1   // load TTBR0
> msr ttbr1_el1, x2   // load TTBR1
> isb
> write_sctlr 

Re: [PATCH RFC v3 2/7] proc: move /proc/{self|thread-self} dentries to proc_fs_info

[Alexey Dobriyan]

On 11/9/17, Djalal Harouni  wrote:

>  struct proc_fs_info {
>   struct pid_namespace *pid_ns;
> + struct dentry *proc_self; /* For /proc/self/ */
> + struct dentry *proc_thread_self; /* For /proc/thread-self/ */

These are redundant comments.

Re: [PATCH RFC v3 1/7] proc: add proc_fs_info struct to store proc information

[Djalal Harouni]

On Fri, Nov 10, 2017 at 11:26 AM, Alexey Dobriyan  wrote:
> On 11/9/17, Djalal Harouni  wrote:
>
>> +struct proc_fs_info {
>> + struct pid_namespace *pid_ns;
>> +};
>
>> +static inline struct proc_fs_info *proc_sb(struct super_block *sb)
>> +{
>> + return sb->s_fs_info;
>> +}
>
> Can you rename this to "struct proc_super_block *" then?
> That "info" suffix all over filesystems doesn't add much info itself
> just more typing.
> Ditto for "fs_info" identifiers.

Ok, will do.

>> +extern inline struct proc_fs_info *proc_sb(struct super_block *sb)
>> { return NULL;}
>
> extern inline?

Oups, sorry will fix it and try to compile without proc.

Thank you!

-- 
tixxdz

Re: [PATCH] lib: test module for find_*_bit() functions

[Alexey Dobriyan]

On 11/10/17, Andrew Morton  wrote:
> On Thu,  9 Nov 2017 17:07:14 +0300 Yury Norov 
> wrote:
>
>> find_bit functions are widely used in the kernel, including hot paths.
>> This module tests performance of that functions in 2 typical scenarios:
>> randomly filled bitmap with relatively equal distribution of set and
>> cleared bits, and sparse bitmap which has 1 set bit for 500 cleared bits.
>>
>> ...
>>
>> +config TEST_FIND_BIT
>
> Well.  It doesn't actually "test" the code.  It measures its performance ;)

Yes!

Yyra, you can grab CONFIG_BENCHMARK_* namespace :-)


Another thing:

> +
> +   return 0;
> +}
> +module_init(find_bit_test);
> +
> +static void __exit test_find_bit_cleanup(void)
> +{
> +}
> +module_exit(test_find_bit_cleanup);

module exit hook is entirely unnecessary as you can return -E from init hook.
See lib/test-kstrtox.c

Re: [PATCH RFC v3 2/7] proc: move /proc/{self|thread-self} dentries to proc_fs_info

[Djalal Harouni]

On Fri, Nov 10, 2017 at 11:31 AM, Alexey Dobriyan  wrote:
> On 11/9/17, Djalal Harouni  wrote:
>
>>  struct proc_fs_info {
>>   struct pid_namespace *pid_ns;
>> + struct dentry *proc_self; /* For /proc/self/ */
>> + struct dentry *proc_thread_self; /* For /proc/thread-self/ */
>
> These are redundant comments.

I can remove them, but actually the area is so difficult and
uncommented that I won't mind extra comments...

Thanks!

-- 
tixxdz

Re: [PATCH 4/4] kbuild: optimize object directory creation for incremental build

[Cao jin]

Masahiro-san

On 11/09/2017 11:41 PM, Masahiro Yamada wrote:
> The previous commit largely optimized the object directory creation.
> We can optimize it more for incremental build.
> 
> There are already *.cmd files in the output directory.  The existing
> *.cmd files have been picked up by $(wildcard ...).  Obviously,
> directories containing them exist too, so we can skip "mkdir -p".
> 
> With this, Kbuild runs almost zero "mkdir -p" in incremental building.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  scripts/Makefile.build | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 89ac180..90ea7a5 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -583,8 +583,13 @@ endif
>  ifneq ($(KBUILD_SRC),)
>  # Create directories for object files if directory does not exist
>  obj-dirs := $(sort $(obj) $(patsubst %/,%, $(dir $(targets
> +# If cmd_files exist, their directories apparently exist.  Skip mkdir.
> +exist-dirs := $(sort $(patsubst %/,%, $(dir $(cmd_files
> +obj-dirs := $(strip $(filter-out . $(exist-dirs), $(obj-dirs)))

First I am not sure if the dot "." here is necessary, because I guess
kbuild always descend into subdir do recursive make, so, very
$(cmd_files) should have at least 1 level dir.

Second, Assuming that "." probably exists, would it be "./"? because it
is what "dir" function returns.

-- 
Sincerely,
Cao jin

> +ifneq ($(obj-dirs),)
>  $(shell mkdir -p $(obj-dirs))
>  endif
> +endif
>  

Re: [PATCH] ASoC: Intel: common: Replace sst_acpi_check_hid with acpi_dev_present

[Hans de Goede]

Hi,

On 09-11-17 22:07, Jeremy Cline wrote:

Replace the sst_acpi_check_hid helper function added in
commit 915ae2b9f0fe ("ASoC: Intel: Create a helper to search for
matching machine") with the generic acpi_dev_present helper function
and remove the now unused sst_acpi_check_hid function. This should have
no functional change.

Signed-off-by: Jeremy Cline 


I've just successfully tested this on an Assu T100HA:

Tested-by: Hans de Goede 
Reviewed-by: Hans de Goede 

Regards,

Hans




---
  sound/soc/intel/common/sst-acpi.h   |  3 ---
  sound/soc/intel/common/sst-match-acpi.c | 32 ++--
  2 files changed, 2 insertions(+), 33 deletions(-)

diff --git a/sound/soc/intel/common/sst-acpi.h 
b/sound/soc/intel/common/sst-acpi.h
index afe9b87b8bd5..d7facac83b7e 100644
--- a/sound/soc/intel/common/sst-acpi.h
+++ b/sound/soc/intel/common/sst-acpi.h
@@ -43,9 +43,6 @@ static inline bool sst_acpi_find_package_from_hid(const u8 
hid[ACPI_ID_LEN],
  /* acpi match */
  struct sst_acpi_mach *sst_acpi_find_machine(struct sst_acpi_mach *machines);
  
-/* acpi check hid */

-bool sst_acpi_check_hid(const u8 hid[ACPI_ID_LEN]);
-
  /* Descriptor for SST ASoC machine driver */
  struct sst_acpi_mach {
/* ACPI ID for the matching machine driver. Audio codec for instance */
diff --git a/sound/soc/intel/common/sst-match-acpi.c 
b/sound/soc/intel/common/sst-match-acpi.c
index 56d26f36a3cb..f8e1b92de79a 100644
--- a/sound/soc/intel/common/sst-match-acpi.c
+++ b/sound/soc/intel/common/sst-match-acpi.c
@@ -49,40 +49,12 @@ const char *sst_acpi_find_name_from_hid(const u8 
hid[ACPI_ID_LEN])
  }
  EXPORT_SYMBOL_GPL(sst_acpi_find_name_from_hid);
  
-static acpi_status sst_acpi_mach_match(acpi_handle handle, u32 level,

-  void *context, void **ret)
-{
-   unsigned long long sta;
-   acpi_status status;
-
-   *(bool *)context = true;
-   status = acpi_evaluate_integer(handle, "_STA", NULL, );
-   if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_PRESENT))
-   *(bool *)context = false;
-
-   return AE_OK;
-}
-
-bool sst_acpi_check_hid(const u8 hid[ACPI_ID_LEN])
-{
-   acpi_status status;
-   bool found = false;
-
-   status = acpi_get_devices(hid, sst_acpi_mach_match, , NULL);
-
-   if (ACPI_FAILURE(status))
-   return false;
-
-   return found;
-}
-EXPORT_SYMBOL_GPL(sst_acpi_check_hid);
-
  struct sst_acpi_mach *sst_acpi_find_machine(struct sst_acpi_mach *machines)
  {
struct sst_acpi_mach *mach;
  
  	for (mach = machines; mach->id[0]; mach++) {

-   if (sst_acpi_check_hid(mach->id) == true) {
+   if (acpi_dev_present(mach->id, NULL, -1) == true) {
if (mach->machine_quirk == NULL)
return mach;
  
@@ -161,7 +133,7 @@ struct sst_acpi_mach *sst_acpi_codec_list(void *arg)

return mach;
  
  	for (i = 0; i < codec_list->num_codecs; i++) {

-   if (sst_acpi_check_hid(codec_list->codecs[i]) != true)
+   if (acpi_dev_present(codec_list->codecs[i], NULL, -1) != true)
return NULL;
}
  

[PATCH v8 4/7] KVM: arm64: Trap RAS error registers and set HCR_EL2's TERR & TEA

[Dongjiu Geng]

ARMv8.2 adds a new bit HCR_EL2.TEA which routes synchronous external
aborts to EL2, and adds a trap control bit HCR_EL2.TERR which traps
all Non-secure EL1&0 error record accesses to EL2.

This patch enables the two bits for the guest OS, guaranteeing that
KVM takes external aborts and traps attempts to access the physical
error registers.

ERRIDR_EL1 advertises the number of error records, we return
zero meaning we can treat all the other registers as RAZ/WI too.

Signed-off-by: Dongjiu Geng 
[removed specific emulation, use trap_raz_wi() directly for everything,
 rephrased parts of the commit message]
Signed-off-by: James Morse 
---
 arch/arm64/include/asm/kvm_arm.h |  2 ++
 arch/arm64/include/asm/kvm_emulate.h |  7 +++
 arch/arm64/include/asm/sysreg.h  | 10 ++
 arch/arm64/kvm/sys_regs.c| 10 ++
 4 files changed, 29 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 61d694c..1188272 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -23,6 +23,8 @@
 #include 
 
 /* Hyp Configuration Register (HCR) bits */
+#define HCR_TEA(UL(1) << 37)
+#define HCR_TERR   (UL(1) << 36)
 #define HCR_E2H(UL(1) << 34)
 #define HCR_ID (UL(1) << 33)
 #define HCR_CD (UL(1) << 32)
diff --git a/arch/arm64/include/asm/kvm_emulate.h 
b/arch/arm64/include/asm/kvm_emulate.h
index e5df3fc..555b28b 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -47,6 +47,13 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
if (is_kernel_in_hyp_mode())
vcpu->arch.hcr_el2 |= HCR_E2H;
+   if (cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) {
+   /* route synchronous external abort exceptions to EL2 */
+   vcpu->arch.hcr_el2 |= HCR_TEA;
+   /* trap error record accesses */
+   vcpu->arch.hcr_el2 |= HCR_TERR;
+   }
+
if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
vcpu->arch.hcr_el2 &= ~HCR_RW;
 }
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 64e2a80..47b967d 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -169,6 +169,16 @@
 #define SYS_AFSR0_EL1  sys_reg(3, 0, 5, 1, 0)
 #define SYS_AFSR1_EL1  sys_reg(3, 0, 5, 1, 1)
 #define SYS_ESR_EL1sys_reg(3, 0, 5, 2, 0)
+
+#define SYS_ERRIDR_EL1 sys_reg(3, 0, 5, 3, 0)
+#define SYS_ERRSELR_EL1sys_reg(3, 0, 5, 3, 1)
+#define SYS_ERXFR_EL1  sys_reg(3, 0, 5, 4, 0)
+#define SYS_ERXCTLR_EL1sys_reg(3, 0, 5, 4, 1)
+#define SYS_ERXSTATUS_EL1  sys_reg(3, 0, 5, 4, 2)
+#define SYS_ERXADDR_EL1sys_reg(3, 0, 5, 4, 3)
+#define SYS_ERXMISC0_EL1   sys_reg(3, 0, 5, 5, 0)
+#define SYS_ERXMISC1_EL1   sys_reg(3, 0, 5, 5, 1)
+
 #define SYS_FAR_EL1sys_reg(3, 0, 6, 0, 0)
 #define SYS_PAR_EL1sys_reg(3, 0, 7, 4, 0)
 
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2e070d3..2b1fafa 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -953,6 +953,16 @@ static bool access_cntp_cval(struct kvm_vcpu *vcpu,
{ SYS_DESC(SYS_AFSR0_EL1), access_vm_reg, reset_unknown, AFSR0_EL1 },
{ SYS_DESC(SYS_AFSR1_EL1), access_vm_reg, reset_unknown, AFSR1_EL1 },
{ SYS_DESC(SYS_ESR_EL1), access_vm_reg, reset_unknown, ESR_EL1 },
+
+   { SYS_DESC(SYS_ERRIDR_EL1), trap_raz_wi },
+   { SYS_DESC(SYS_ERRSELR_EL1), trap_raz_wi },
+   { SYS_DESC(SYS_ERXFR_EL1), trap_raz_wi },
+   { SYS_DESC(SYS_ERXCTLR_EL1), trap_raz_wi },
+   { SYS_DESC(SYS_ERXSTATUS_EL1), trap_raz_wi },
+   { SYS_DESC(SYS_ERXADDR_EL1), trap_raz_wi },
+   { SYS_DESC(SYS_ERXMISC0_EL1), trap_raz_wi },
+   { SYS_DESC(SYS_ERXMISC1_EL1), trap_raz_wi },
+
{ SYS_DESC(SYS_FAR_EL1), access_vm_reg, reset_unknown, FAR_EL1 },
{ SYS_DESC(SYS_PAR_EL1), NULL, reset_unknown, PAR_EL1 },
 
-- 
1.9.1

[PATCH v8 2/7] KVM: arm64: Save ESR_EL2 on guest SError

[Dongjiu Geng]

From: James Morse 

When we exit a guest due to an SError the vcpu fault info isn't updated
with the ESR. Today this is only done for traps.

The v8.2 RAS Extensions define ISS values for SError. Update the vcpu's
fault_info with the ESR on SError so that handle_exit() can determine
if this was a RAS SError and decode its severity.

Signed-off-by: James Morse 
Signed-off-by: Dongjiu Geng 
---
 arch/arm64/kvm/hyp/switch.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 945e79c..c6f17c7 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -226,13 +226,20 @@ static bool __hyp_text __translate_far_to_hpfar(u64 far, 
u64 *hpfar)
return true;
 }
 
+static void __hyp_text __populate_fault_info_esr(struct kvm_vcpu *vcpu)
+{
+   vcpu->arch.fault.esr_el2 = read_sysreg_el2(esr);
+}
+
 static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
 {
-   u64 esr = read_sysreg_el2(esr);
-   u8 ec = ESR_ELx_EC(esr);
+   u8 ec;
+   u64 esr;
u64 hpfar, far;
 
-   vcpu->arch.fault.esr_el2 = esr;
+   __populate_fault_info_esr(vcpu);
+   esr = vcpu->arch.fault.esr_el2;
+   ec = ESR_ELx_EC(esr);
 
if (ec != ESR_ELx_EC_DABT_LOW && ec != ESR_ELx_EC_IABT_LOW)
return true;
@@ -321,6 +328,8 @@ int __hyp_text __kvm_vcpu_run(struct kvm_vcpu *vcpu)
 */
if (exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
goto again;
+   else if (ARM_EXCEPTION_CODE(exit_code) == ARM_EXCEPTION_EL1_SERROR)
+   __populate_fault_info_esr(vcpu);
 
if (static_branch_unlikely(_v2_cpuif_trap) &&
exit_code == ARM_EXCEPTION_TRAP) {
-- 
1.9.1

[PATCH v8 0/7] Support RAS virtualization in KVM

[Dongjiu Geng]

This series patches mainly do below things:

1. Trap RAS ERR* registers Accesses to EL2 from Non-secure EL1,
   KVM will will do a minimum simulation, there registers are simulated
   to RAZ/WI in KVM.
2. Route synchronous External Abort exceptions from Non-secure EL0
   and EL1 to EL2. When exception EL3 routing is enabled by firmware,
   system will trap to EL3 firmware instead of EL2 KVM, then firmware
   judges whether El2 routing is enabled, if enabled, jump to EL2 KVM, 
   otherwise jump to EL1 host kernel.
3. Enable APEI ARv8 SEI notification to parse the CPER records for SError
   in the ACPI GHES driver, KVM will call handle_guest_sei() to let ACPI
   driver to parse the CPER record for SError which happened in the guest
4. Although we can use APEI driver to handle the guest SError, but not all
   system support SEI notification, such as kernel-first. So here KVM will
   also classify the Error through Exception Syndrome Register and do different
   approaches according to Asynchronous Error Type
5. If the guest SError error is not propagated and not consumed, then KVM return
   recoverable error status to user-space, user-space will specify the guest ESR
   and inject a virtual SError. For other Asynchronous Error Type, KVM directly
   injects virtual SError with IMPLEMENTATION DEFINED ESR or KVM is panic if the
   error is fatal. In the RAS extension, guest virtual ESR must be set, because
   all-zero  means 'RAS error: Uncategorized' instead of 'no valid ISS', so set
   this ESR to IMPLEMENTATION DEFINED by default if user space does not specify 
it.

Dongjiu Geng (5):
  acpi: apei: Add SEI notification type support for ARMv8
  KVM: arm64: Trap RAS error registers and set HCR_EL2's TERR & TEA
  arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl
  arm64: kvm: Set Virtual SError Exception Syndrome for guest
  arm64: kvm: handle SError Interrupt by categorization

James Morse (1):
  KVM: arm64: Save ESR_EL2 on guest SError

Xie XiuQi (1):
  arm64: cpufeature: Detect CPU RAS Extentions

 Documentation/virtual/kvm/api.txt| 11 ++
 arch/arm/include/asm/kvm_host.h  |  1 +
 arch/arm/kvm/guest.c |  9 +
 arch/arm64/Kconfig   | 16 +
 arch/arm64/include/asm/barrier.h |  1 +
 arch/arm64/include/asm/cpucaps.h |  3 +-
 arch/arm64/include/asm/esr.h | 15 
 arch/arm64/include/asm/kvm_arm.h |  2 ++
 arch/arm64/include/asm/kvm_asm.h |  3 ++
 arch/arm64/include/asm/kvm_emulate.h | 17 +
 arch/arm64/include/asm/kvm_host.h|  2 ++
 arch/arm64/include/asm/sysreg.h  | 15 
 arch/arm64/include/asm/system_misc.h |  1 +
 arch/arm64/kernel/cpufeature.c   | 13 +++
 arch/arm64/kernel/process.c  |  3 ++
 arch/arm64/kvm/guest.c   | 14 
 arch/arm64/kvm/handle_exit.c | 67 +---
 arch/arm64/kvm/hyp/switch.c  | 31 +++--
 arch/arm64/kvm/inject_fault.c| 13 ++-
 arch/arm64/kvm/reset.c   |  3 ++
 arch/arm64/kvm/sys_regs.c| 10 ++
 arch/arm64/mm/fault.c| 16 +
 drivers/acpi/apei/Kconfig| 15 
 drivers/acpi/apei/ghes.c | 53 
 include/acpi/ghes.h  |  1 +
 include/uapi/linux/kvm.h |  3 ++
 virt/kvm/arm/arm.c   |  7 
 27 files changed, 336 insertions(+), 9 deletions(-)

-- 
1.9.1

[PATCH v8 3/7] acpi: apei: Add SEI notification type support for ARMv8

[Dongjiu Geng]

ARMv8.2 requires implementation of the RAS extension, in
this extension it adds SEI(SError Interrupt) notification
type, this patch adds new GHES error source SEI handling
functions. This error source parsing and handling method
is similar with the SEA.

Expose API ghes_notify_sei() to external users. External
modules can call this exposed API to parse APEI table and
handle the SEI notification.

Signed-off-by: Dongjiu Geng 
---
 drivers/acpi/apei/Kconfig | 15 ++
 drivers/acpi/apei/ghes.c  | 53 +++
 include/acpi/ghes.h   |  1 +
 3 files changed, 69 insertions(+)

diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index 52ae543..ff4afc3 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -55,6 +55,21 @@ config ACPI_APEI_SEA
  option allows the OS to look for such hardware error record, and
  take appropriate action.
 
+config ACPI_APEI_SEI
+   bool "APEI SError(System Error) Interrupt logging/recovering support"
+   depends on ARM64 && ACPI_APEI_GHES
+   default y
+   help
+ This option should be enabled if the system supports
+ firmware first handling of SEI (SError interrupt).
+
+ SEI happens with asynchronous external abort for errors on device
+ memory reads on ARMv8 systems. If a system supports firmware first
+ handling of SEI, the platform analyzes and handles hardware error
+ notifications from SEI, and it may then form a hardware error record 
for
+ the OS to parse and handle. This option allows the OS to look for
+ such hardware error record, and take appropriate action.
+
 config ACPI_APEI_MEMORY_FAILURE
bool "APEI memory error recovering support"
depends on ACPI_APEI && MEMORY_FAILURE
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 6a3f824..67cd3a7 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -855,6 +855,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { }
 static inline void ghes_sea_remove(struct ghes *ghes) { }
 #endif /* CONFIG_ACPI_APEI_SEA */
 
+#ifdef CONFIG_ACPI_APEI_SEI
+static LIST_HEAD(ghes_sei);
+
+/*
+ * Return 0 only if one of the SEI error sources successfully reported an error
+ * record sent from the firmware.
+ */
+int ghes_notify_sei(void)
+{
+   struct ghes *ghes;
+   int ret = -ENOENT;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(ghes, _sei, list) {
+   if (!ghes_proc(ghes))
+   ret = 0;
+   }
+   rcu_read_unlock();
+   return ret;
+}
+
+static void ghes_sei_add(struct ghes *ghes)
+{
+   mutex_lock(_list_mutex);
+   list_add_rcu(>list, _sei);
+   mutex_unlock(_list_mutex);
+}
+
+static void ghes_sei_remove(struct ghes *ghes)
+{
+   mutex_lock(_list_mutex);
+   list_del_rcu(>list);
+   mutex_unlock(_list_mutex);
+   synchronize_rcu();
+}
+#else /* CONFIG_ACPI_APEI_SEI */
+static inline void ghes_sei_add(struct ghes *ghes) { }
+static inline void ghes_sei_remove(struct ghes *ghes) { }
+#endif /* CONFIG_ACPI_APEI_SEI */
+
 #ifdef CONFIG_HAVE_ACPI_APEI_NMI
 /*
  * printk is not safe in NMI context.  So in NMI handler, we allocate
@@ -1086,6 +1126,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
goto err;
}
break;
+   case ACPI_HEST_NOTIFY_SEI:
+   if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) {
+   pr_warn(GHES_PFX "Generic hardware error source: %d 
notified via SEI is not supported!\n",
+   generic->header.source_id);
+   goto err;
+   }
+   break;
case ACPI_HEST_NOTIFY_NMI:
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
pr_warn(GHES_PFX "Generic hardware error source: %d 
notified via NMI interrupt is not supported!\n",
@@ -1158,6 +1205,9 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_add(ghes);
break;
+   case ACPI_HEST_NOTIFY_SEI:
+   ghes_sei_add(ghes);
+   break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
@@ -1211,6 +1261,9 @@ static int ghes_remove(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_remove(ghes);
break;
+   case ACPI_HEST_NOTIFY_SEI:
+   ghes_sei_remove(ghes);
+   break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 8feb0c8..9ba59e2 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct 
acpi_hest_generic_data *gdata)
 section = 

[no subject]

[Jagan Teki]

unsubscribe linux-mtd

Re: [PATCH v6 00/10] rockchip: kevin: Enable edp display

[Enric Balletbo Serra]

Dear all,

2017-11-01 20:33 GMT+01:00 Sean Paul :
> On Tue, Oct 31, 2017 at 12:37:43PM +0800, JeffyChen wrote:
>> Hi Heiko,
>>
>> On 10/31/2017 07:01 AM, Heiko Stuebner wrote:
>> > As I was just looking at the edp dts change in patch1 again, does this
>> > series also contain a fix for the issue below [0] ?
>> >
>> > I'm still seeing this on 4.14-rc6 with the most recent drm tree merged in.
>> >
>> i saw that too, it should due to our psr code...i think Zain has solved
>> these in chromeos kernel, i will ask Zain if he have time to upstream them,
>> or maybe i'll try to upstream them.
>
> You need the patchset where I've refactored the psr locking/workers. I have a
> version of it based on Heiko's tree at
> https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=rk3399-display
>
> With this kernel, the backlight comes on, but I don't have anything on the
> display (which is why I didn't post it). I'll try putting this set on top and
> see what happens.
>

There is a patch in the ML sent by Emil [1], similar to the Sean
patch, that solves the issue.

And I can confirm that the Jeffy's patches + Emil patch makes the
display work on kevin or current rc8

[1] https://patchwork.kernel.org/patch/9985237/

Enric

> Sean
>
>> >
>> > Heiko
>> >
>> > [0]
>> >
>> > [   27.960120] BUG: scheduling while atomic: kworker/1:1/68/0x0002
>> > [   27.974429] Modules linked in: rockchipdrm dw_hdmi analogix_dp 
>> > drm_kms_helper panel_simple crc32_ce drm crct10dif_ce rockchip_saradc 
>> > pwm_bl pwm_cros_ec rockchip_thermal ip_tables x_tabl
>> > es ipv6 smsc95xx smsc75xx ax88179_178a asix usbnet phy_rockchip_pcie 
>> > pcie_rockchip
>> > [   28.008769] CPU: 1 PID: 68 Comm: kworker/1:1 Tainted: GW   
>> > 4.14.0-rc7-03201-g12490811b353 #559
>> > [   28.008774] Hardware name: Google Kevin (DT)
>> > [   28.008825] Workqueue: events analogix_dp_psr_work [rockchipdrm]
>> > [   28.008828] Call trace:
>> > [   28.008838] [] dump_backtrace+0x0/0x378
>> > [   28.008842] [] show_stack+0x14/0x20
>> > [   28.008847] [] dump_stack+0x9c/0xbc
>> > [   28.008852] [] __schedule_bug+0x4c/0x70
>> > [   28.008856] [] __schedule+0x558/0x5e8
>> > [   28.008859] [] schedule+0x38/0xa0
>> > [   28.008864] [] 
>> > schedule_hrtimeout_range_clock+0x84/0xe8
>> > [   28.008867] [] schedule_hrtimeout_range+0x10/0x18
>> > [   28.008870] [] usleep_range+0x64/0x78
>> > [   28.008882] [] analogix_dp_transfer+0x16c/0xa88 
>> > [analogix_dp]
>> > [   28.008891] [] analogix_dpaux_transfer+0x10/0x18 
>> > [analogix_dp]
>> > [   28.008950] [] drm_dp_dpcd_access+0x4c/0xf8 
>> > [drm_kms_helper]
>> > [   28.008994] [] drm_dp_dpcd_write+0x1c/0x28 
>> > [drm_kms_helper]
>> > [   28.009002] [] analogix_dp_disable_psr+0x60/0xb0 
>> > [analogix_dp]
>> > [   28.009036] [] analogix_dp_psr_work+0x4c/0xc0 
>> > [rockchipdrm]
>> > [   28.009040] [] process_one_work+0x1d4/0x348
>> > [   28.009043] [] worker_thread+0x48/0x470
>> > [   28.009048] [] kthread+0x12c/0x130
>> > [   28.009052] [] ret_from_fork+0x10/0x18
>> >
>> >
>> >
>> >
>>
>>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy (was: Re: [RESEND PATCH] mm, oom_reaper: gather each vma to prevent) leaking TLB entry

[Michal Hocko]

On Fri 10-11-17 11:15:29, Michal Hocko wrote:
> On Fri 10-11-17 09:19:33, Minchan Kim wrote:
> > On Tue, Nov 07, 2017 at 09:54:53AM +, Wang Nan wrote:
> > > tlb_gather_mmu(, mm, 0, -1) means gathering the whole virtual memory
> > > space. In this case, tlb->fullmm is true. Some archs like arm64 doesn't
> > > flush TLB when tlb->fullmm is true:
> > > 
> > >   commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 
> > > 1").
> > > 
> > > Which makes leaking of tlb entries.
> > 
> > That means soft-dirty which has used tlb_gather_mmu with fullmm could be
> > broken via losing write-protection bit once it supports arm64 in future?
> > 
> > If so, it would be better to use TASK_SIZE rather than -1 in tlb_gather_mmu.
> > Of course, it's a off-topic.
> 
> I wouldn't play tricks like that. And maybe the API itself could be more
> explicit. E.g. add a lazy parameter which would allow arch specific code
> to not flush if it is sure that nobody can actually stumble over missed
> flush. E.g. the following?

This one has a changelog and even compiles on my crosscompile test
---
>From 7f0fcd2cab379ddac5611b2a520cdca8a77a235b Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Fri, 10 Nov 2017 11:27:17 +0100
Subject: [PATCH] arch, mm: introduce arch_tlb_gather_mmu_lazy

5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1") has
introduced an optimization to not flush tlb when we are tearing the
whole address space down. Will goes on to explain

: Basically, we tag each address space with an ASID (PCID on x86) which
: is resident in the TLB. This means we can elide TLB invalidation when
: pulling down a full mm because we won't ever assign that ASID to
: another mm without doing TLB invalidation elsewhere (which actually
: just nukes the whole TLB).

This all is nice but tlb_gather users are not aware of that and this can
actually cause some real problems. E.g. the oom_reaper tries to reap the
whole address space but it might race with threads accessing the memory [1].
It is possible that soft-dirty handling might suffer from the same
problem [2].

Introduce an explicit lazy variant tlb_gather_mmu_lazy which allows the
behavior arm64 implements for the fullmm case and replace it by an
explicit lazy flag in the mmu_gather structure. exit_mmap path is then
turned into the explicit lazy variant. Other architectures simply ignore
the flag.

[1] http://lkml.kernel.org/r/20171106033651.172368-1-wangn...@huawei.com
[2] http://lkml.kernel.org/r/20171110001933.GA12421@bbox
Signed-off-by: Michal Hocko 
---
 arch/arm/include/asm/tlb.h   |  3 ++-
 arch/arm64/include/asm/tlb.h |  2 +-
 arch/ia64/include/asm/tlb.h  |  3 ++-
 arch/s390/include/asm/tlb.h  |  3 ++-
 arch/sh/include/asm/tlb.h|  2 +-
 arch/um/include/asm/tlb.h|  2 +-
 include/asm-generic/tlb.h|  6 --
 include/linux/mm_types.h |  2 ++
 mm/memory.c  | 17 +++--
 mm/mmap.c|  2 +-
 10 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index d5562f9ce600..fe9042aee8e9 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -149,7 +149,8 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
 
 static inline void
 arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
-   unsigned long start, unsigned long end)
+   unsigned long start, unsigned long end,
+   bool lazy)
 {
tlb->mm = mm;
tlb->fullmm = !(start | (end+1));
diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
index ffdaea7954bb..7adde19b2bcc 100644
--- a/arch/arm64/include/asm/tlb.h
+++ b/arch/arm64/include/asm/tlb.h
@@ -43,7 +43,7 @@ static inline void tlb_flush(struct mmu_gather *tlb)
 * The ASID allocator will either invalidate the ASID or mark
 * it as used.
 */
-   if (tlb->fullmm)
+   if (tlb->lazy)
return;
 
/*
diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h
index cbe5ac3699bf..50c440f5b7bc 100644
--- a/arch/ia64/include/asm/tlb.h
+++ b/arch/ia64/include/asm/tlb.h
@@ -169,7 +169,8 @@ static inline void __tlb_alloc_page(struct mmu_gather *tlb)
 
 static inline void
 arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
-   unsigned long start, unsigned long end)
+   unsigned long start, unsigned long end,
+   bool lazy)
 {
tlb->mm = mm;
tlb->max = ARRAY_SIZE(tlb->local);
diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index 2eb8ff0d6fca..2310657b64c4 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -49,7 +49,8 @@ extern void tlb_remove_table(struct mmu_gather *tlb, void 
*table);
 
 static inline void
 arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
- 

Re: [PATCH V13 05/10] mmc: cqhci: support for command queue enabled host

[Linus Walleij]

On Thu, Nov 9, 2017 at 1:55 PM, Adrian Hunter  wrote:
> On 09/11/17 14:26, Linus Walleij wrote:

 I think the above approach to put any CQE-specific callbacks
 directly into the struct mmc_host_ops is way more viable.
>>>
>>> Nothing to do with CQE.  This is CQHCI.  Please try to get the difference.
>>
>> I am trying, please try to think about your language.
>
> I strongly disapprove of being rude but sadly it seems to get results.

Conflict is a natural part of human existence. Using it deliberately
to get one's way is manipulation. Admitting to being manipulative
is losing one's face in public.

Yours,
Linus Walleij

Re: [PATCH] sched/fair: Consider RT/IRQ pressure in capacity_spare_wake

[Vincent Guittot]

On 9 November 2017 at 19:52, Joel Fernandes  wrote:
> capacity_spare_wake in the slow path influences choice of idlest groups,
> as we search for groups with maximum spare capacity. In scenarios where
> RT pressure is high, a sub optimal group can be chosen and hurt
> performance of the task being woken up.
>
> Several tests with results are included below to show improvements with
> this change.
>
> 1) Hackbench on Pixel 2 Android device (4x4 ARM64 Octa core)

"4x4 ARM64 Octa core" is confusing . At least for me, 4x4 means 16 cores :-)

> 
> Here we have RT activity running on big CPU cluster induced with rt-app,
> and running hackbench in parallel. The RT tasks are bound to 4 CPUs on
> the big cluster (cpu 4,5,6,7) and have 100ms periodicity with
> runtime=20ms sleep=80ms.
>
> Hackbench shows big benefit (30%) improvement when number of tasks is 8
> and 32: Note: data is completion time in seconds (lower is better).
> Number of loops for 8 and 16 tasks is 5, and for 32 tasks its 2.
> ++-+---+---+---+
> | groups | fds | tasks | Without Patch | With Patch|
> ++-+---+-+-+-+-+
> || |   | Mean| Stdev   | Mean| Stdev   |
> || |   +---+-+-+
> |  1 |   8 | 8 | 1.0534  | 0.13722 | 0.7293 (+30.7%) | 0.02653 |
> |  2 |   8 |16 | 1.6219  | 0.16631 | 1.6391 (-1%)| 0.24001 |
> |  4 |   8 |32 | 1.2538  | 0.13086 | 1.1080 (+11.6%) | 0.16201 |
> ++-+---+-+-+-+-+

 Out of curiosity, do you know why you don't see any improvement for
16 tasks but only for 8 and 32 tasks ?

>
> 2) Rohit ran barrier.c test (details below) with following improvements:
> 
> This was Rohit's original use case for a patch he posted at [1] however
> from his recent tests he showed my patch can replace his slow path
> changes [1] and there's no need to selectively scan/skip CPUs in
> find_idlest_group_cpu in the slow path to get the improvement he sees.
>
> barrier.c (open_mp code) as a micro-benchmark. It does a number of
> iterations and barrier sync at the end of each for loop.
>
> Here barrier,c is running in along with ping on CPU 0 and 1 as:
> 'ping -l 1 -q -s 10 -f hostX'
>
> barrier.c can be found at:
> http://www.spinics.net/lists/kernel/msg2506955.html
>
> Following are the results for the iterations per second with this
> micro-benchmark (higher is better), on a 44 core, 2 socket 88 Threads
> Intel x86 machine:
> ++--+---+
> |Threads | Without patch| With patch|
> ||  |   |
> +++-+-+-+
> || Mean   | Std Dev | Mean| Std Dev |
> +++-+-+-+
> |1   | 539.36 | 60.16   | 572.54 (+6.15%) | 40.95   |
> |2   | 481.01 | 19.32   | 530.64 (+10.32%)| 56.16   |
> |4   | 474.78 | 22.28   | 479.46 (+0.99%) | 18.89   |
> |8   | 450.06 | 24.91   | 447.82 (-0.50%) | 12.36   |
> |16  | 436.99 | 22.57   | 441.88 (+1.12%) | 7.39|
> |32  | 388.28 | 55.59   | 429.4  (+10.59%)| 31.14   |
> |64  | 314.62 | 6.33| 311.81 (-0.89%) | 11.99   |
> +++-+-+-+
>
> 3) ping+hackbench test on bare-metal sever (Rohit ran this test)
> 
> Here hackbench is running in threaded mode along
> with, running ping on CPU 0 and 1 as:
> 'ping -l 1 -q -s 10 -f hostX'
>
> This test is running on 2 socket, 20 core and 40 threads Intel x86
> machine:
> Number of loops is 1 and runtime is in seconds (Lower is better).
>
> +--+-+--+
> |Task Groups   | Without patch   |  With patch  |
> |  +---+-++-+
> |(Groups of 40)| Mean  | Std Dev |  Mean  | Std Dev |
> +--+---+-++-+
> |1 | 0.851 | 0.007   |  0.828 (+2.77%)| 0.032   |
> |2 | 1.083 | 0.203   |  1.087 (-0.37%)| 0.246   |
> |4 | 1.601 | 0.051   |  1.611 (-0.62%)| 0.055   |
> |8 | 2.837 | 0.060   |  2.827 (+0.35%)| 0.031   |
> |16| 5.139 | 0.133   |  5.107 (+0.63%)| 0.085   |
> |25| 7.569 | 0.142   |  7.503 (+0.88%)| 0.143   |
> +--+---+-++-+
>
> [1] https://patchwork.kernel.org/patch/9991635/
>
> Matt Fleming also ran cyclictest and several different hackbench tests
> on his test machines to santiy-check that the patch 

Re: [PATCH 02/14] soundwire: Add SoundWire bus type

[Vinod Koul]

On Fri, Nov 10, 2017 at 10:29:51AM +0530, Vinod Koul wrote:
> On Thu, Nov 09, 2017 at 09:14:07PM +, Srinivas Kandagatla wrote:
> > 
> > 
> > On 19/10/17 04:03, Vinod Koul wrote:
> > >This adds the base SoundWire bus type, bus and driver registration.
> > >along with changes to module device table for new SoundWire
> > >device type.
> > >
> > >Signed-off-by: Sanyog Kale 
> > >Signed-off-by: Vinod Koul 
> > >---
> > 
> > >+++ b/drivers/soundwire/Kconfig
> > >@@ -0,0 +1,22 @@
> > >+#
> > >+# SoundWire subsystem configuration
> > >+#
> > >+
> > >+menuconfig SOUNDWIRE
> > >+  bool "SoundWire support"
> > 
> > Any reason why this subsystem can not be build as module?
> 
> This is not subsystem symbol but the menu. The SOUNDWIRE_BUS can be module.
> 
> > 
> > >+  ---help---
> > >+SoundWire is a 2-Pin interface with data and clock line ratified
> > >+by the MIPI Alliance. SoundWire is used for transporting data
> > >+typically related to audio functions. SoundWire interface is
> > 
> > >+#ifndef __SDW_BUS_H
> > >+#define __SDW_BUS_H
> > >+
> > >+#include 
> > >+#include 
> > >+#include 
> > >+#include 
> > >+#include 
> > Do you need these headers here?
> 
> Yes :) I will double check though
> 
> 
> > 
> > >+#include 
> > >+
> > >+int sdw_slave_modalias(struct sdw_slave *slave, char *buf, size_t size);
> > >+
> > >+#endif /* __SDW_BUS_H */
> > >diff --git a/drivers/soundwire/bus_type.c b/drivers/soundwire/bus_type.c
> > >new file mode 100644
> > >index ..a14d1de80afa
> > >--- /dev/null
> > >+++ b/drivers/soundwire/bus_type.c
> > >
> > >+#include 
> > >+#include 
> > >+#include 
> > >+#include 
> > >+#include 
> > >+#include 
> > >+#include 
> > >+#include 
> > >+#include "bus.h"
> > >+
> > >+/**
> > >+ * sdw_get_device_id: find the matching SoundWire device id
> > >+ *
> > function name should end with () - according to kernel doc.
> 
> ah thanks for pointing will add

I ran the kernel-doc script, seems to not complain about this.

Looking at it closely scripts/kernel-doc parenthesis is not expected

-- 
~Vinod

Re: [PATCH 2/4] x86/boot/compressed/64: Detect and handle 5-level paging at boot-time

[Ingo Molnar]

* Kirill A. Shutemov  wrote:

> This patch prepare decompression code to boot-time switching between 4-
> and 5-level paging.
> 
> Signed-off-by: Kirill A. Shutemov 
> ---
>  arch/x86/boot/compressed/head_64.S   | 16 
>  arch/x86/boot/compressed/pagetable.c | 19 +++
>  2 files changed, 31 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/head_64.S 
> b/arch/x86/boot/compressed/head_64.S
> index b4a5d284391c..6ac8239af2b6 100644
> --- a/arch/x86/boot/compressed/head_64.S
> +++ b/arch/x86/boot/compressed/head_64.S
> @@ -288,10 +288,18 @@ ENTRY(startup_64)
>   leaqboot_stack_end(%rbx), %rsp
>  
>  #ifdef CONFIG_X86_5LEVEL
> - /* Check if 5-level paging has already enabled */
> - movq%cr4, %rax
> - testl   $X86_CR4_LA57, %eax
> - jnz lvl5
> + /*
> +  * Check if we need to enable 5-level paging.
> +  * RSI holds real mode data and need to be preserved across
> +  * a function call.
> +  */
> + pushq   %rsi
> + callneed_to_enabled_l5
> + popq%rsi
> +
> + /* If need_to_enabled_l5() returned zero, we're done here. */
> + cmpq$0, %rax
> + je  lvl5
>  
>   /*
>* At this point we are in long mode with 4-level paging enabled,
> diff --git a/arch/x86/boot/compressed/pagetable.c 
> b/arch/x86/boot/compressed/pagetable.c
> index a15bbfcb3413..cd2dd49333cc 100644
> --- a/arch/x86/boot/compressed/pagetable.c
> +++ b/arch/x86/boot/compressed/pagetable.c
> @@ -154,3 +154,22 @@ void finalize_identity_maps(void)
>  }
>  
>  #endif /* CONFIG_RANDOMIZE_BASE */
> +
> +#ifdef CONFIG_X86_5LEVEL
> +int need_to_enabled_l5(void)
> +{
> + /* Check i leaf 7 is supported. */
> + if (native_cpuid_eax(0) < 7)
> + return 0;
> +
> + /* Check if la57 is supported. */
> + if (!(native_cpuid_ecx(7) & (1 << (X86_FEATURE_LA57 & 31
> + return 0;
> +
> + /* Check if 5-level paging has already been enabled. */
> + if (native_read_cr4() & X86_CR4_LA57)
> + return 0;
> +
> + return 1;
> +}
> +#endif

Ok, I like this a lot better than doing this at the assembly level - and this 
could provide a model for how to further reduce assembly code.

Thanks,

Ingo

Re: [PATCH v5 10/26] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass

[Christoffer Dall]

On Fri, Nov 10, 2017 at 10:05 AM, Marc Zyngier  wrote:
> On 10/11/17 08:28, Christoffer Dall wrote:
>> Hi Eric and Marc,
>>
>> On Tue, Nov 07, 2017 at 02:42:44PM +, Marc Zyngier wrote:
>>> Hi Eric,
>>>
>>> On 07/11/17 13:06, Auger Eric wrote:
 Hi Marc,

 On 27/10/2017 16:28, Marc Zyngier wrote:
> Let's use the irq bypass mechanism introduced for platform device
> interrupts
 nit: I would remove "introduced for platform device interrupts"
 as this is not upstream yet. x86 posted interrupts also use it.

>
  and establish our LPI->VLPI mapping.
>>
>> I have tweaked the commit message.
>>
>
> Reviewed-by: Christoffer Dall 
> Signed-off-by: Marc Zyngier 
> ---
>  include/kvm/arm_vgic.h  |   8 
>  virt/kvm/arm/arm.c  |   6 ++-
>  virt/kvm/arm/vgic/vgic-v4.c | 108 
> 
>  3 files changed, 120 insertions(+), 2 deletions(-)
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 7eeb6c2a2f9c..2f750c770bf2 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -373,4 +373,12 @@ int kvm_vgic_setup_default_irq_routing(struct kvm 
> *kvm);
>
>  int kvm_vgic_set_owner(struct kvm_vcpu *vcpu, unsigned int intid, void 
> *owner);
>
> +struct kvm_kernel_irq_routing_entry;
> +
> +int kvm_vgic_v4_set_forwarding(struct kvm *kvm, int irq,
> + struct kvm_kernel_irq_routing_entry *irq_entry);
> +
> +int kvm_vgic_v4_unset_forwarding(struct kvm *kvm, int irq,
> +   struct kvm_kernel_irq_routing_entry 
> *irq_entry);
> +
>  #endif /* __KVM_ARM_VGIC_H */
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 5d5218ecd547..8388c1cc23f6 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -1462,7 +1462,8 @@ int kvm_arch_irq_bypass_add_producer(struct 
> irq_bypass_consumer *cons,
>struct kvm_kernel_irqfd *irqfd =
>container_of(cons, struct kvm_kernel_irqfd, consumer);
>
> -  return 0;
> +  return kvm_vgic_v4_set_forwarding(irqfd->kvm, prod->irq,
> +>irq_entry);
>  }
>  void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
>  struct irq_bypass_producer *prod)
> @@ -1470,7 +1471,8 @@ void kvm_arch_irq_bypass_del_producer(struct 
> irq_bypass_consumer *cons,
>struct kvm_kernel_irqfd *irqfd =
>container_of(cons, struct kvm_kernel_irqfd, consumer);
>
> -  return;
> +  kvm_vgic_v4_unset_forwarding(irqfd->kvm, prod->irq,
> +   >irq_entry);
>  }
>
>  void kvm_arch_irq_bypass_stop(struct irq_bypass_consumer *cons)
> diff --git a/virt/kvm/arm/vgic/vgic-v4.c b/virt/kvm/arm/vgic/vgic-v4.c
> index c794f0cef09e..01a2889b7b7c 100644
> --- a/virt/kvm/arm/vgic/vgic-v4.c
> +++ b/virt/kvm/arm/vgic/vgic-v4.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "vgic.h"
>
> @@ -81,3 +82,110 @@ void vgic_v4_teardown(struct kvm *kvm)
>its_vm->nr_vpes = 0;
>its_vm->vpes = NULL;
>  }
> +
> +static struct vgic_its *vgic_get_its(struct kvm *kvm,
> +   struct kvm_kernel_irq_routing_entry 
> *irq_entry)
> +{
> +  struct kvm_msi msi  = (struct kvm_msi) {
> +  .address_lo = irq_entry->msi.address_lo,
> +  .address_hi = irq_entry->msi.address_hi,
> +  .data   = irq_entry->msi.data,
> +  .flags  = irq_entry->msi.flags,
> +  .devid  = irq_entry->msi.devid,
> +  };
> +
> +  /*
> +   * Get a reference on the LPI. If NULL, this is not a valid
> +   * translation for any of our vITSs.
> +   */
 I don't understand the relevance of the above comment.
>>>
>>> Hmmm. The first part looks like an outdated leftover, as the ITS is not
>>> refcounted, and we don't deal with LPIs here.
>>>
>>
>> I simply removed this comment.
>>
>> [...]
>>
>> I think the only thing left to fix on this patch is the IRQ_DISABLE_LAZY
>> thing on its_map_vlpi() failures, which Marc can fix post -rc1.
>
> Here's what I've queued on the irqchip side:
>
> From 9c0733704b99c89773416af3a412332b0e8bd2a4 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier 
> Date: Fri, 10 Nov 2017 09:00:41 +
> Subject: [PATCH] irqchip/gic-v4: Clear IRQ_DISABLE_UNLAZY again if mapping
>  fails
>
> Should the call to irq_set_vcpu_affinity() fail at map time,
> we should restore the normal lazy-disable behaviour instead
> of staying with the eager disable that GICv4 requires.
>
> Reported-by: Eric 

Re: [PATCH 3/4] x86/boot/compressed/64: Introduce place_trampoline()

[Kirill A. Shutemov]

On Fri, Nov 10, 2017 at 10:28:12AM +0100, Ingo Molnar wrote:
> 
> * Ingo Molnar  wrote:
> 
> > > --- a/arch/x86/boot/compressed/head_64.S
> > > +++ b/arch/x86/boot/compressed/head_64.S
> > > @@ -315,6 +315,18 @@ ENTRY(startup_64)
> > >* The first step is go into compatibility mode.
> > >*/
> > >  
> > > + /*
> > > +  * Find suitable place for trampoline and populate it.
> > > +  * The address will be stored in RCX.
> > > +  *
> > > +  * RSI holds real mode data and need to be preserved across
> > > +  * a function call.
> > > +  */
> > > + pushq   %rsi
> > > + callplace_trampoline
> > > + popq%rsi
> > > + movq%rax, %rcx
> > > +
> > >   /* Clear additional page table */
> > >   leaqlvl5_pgtable(%rbx), %rdi
> > >   xorq%rax, %rax
> > 
> > One request: it's always going to be fragile if the _only_ thing that uses 
> > the 
> > trampoline is the 5-level paging code.
> > 
> > Could we use the trampoline in the 4-level paging case too? It's not 
> > required, but 
> > would test much of the trampoline allocation and copying machinery - and 
> > the 
> > performance cost is negligible.
> 
> Note that right now the trampoline is pointless on 4-level setups, so there's 
> nothing to copy - but we could perhaps make it meaningful. But maybe it's not 
> a 
> good idea.

Let me see how it will play out.

> One other detail I noticed:
> 
> /* Bound size of trampoline code */
> .orglvl5_trampoline_src + LVL5_TRAMPOLINE_CODE_SIZE
> 
> will this generate a build error if the trampoline code exceeds 0x40?

Yes, this is the point. Just a failsafe if trampoline code would grew too
much.

-- 
 Kirill A. Shutemov

Re: [PATCH 26/30] Lock down ftrace

[David Howells]

Jiri Kosina  wrote:

> > The idea is to prevent cryptographic data for filesystems and other things
> > from being read out of the kernel memory as well as to prevent unauthorised
> > modification of kernel memory.
> 
> Then it would make sense to actually lock down dumping of registers / 
> function arguments (kprobes can currently do that, ftrace eventually could 
> as well I guess), but disabling the whole ftrace altogether seems like a 
> totally unnecessary overkill.

That would be fine by me.  I have a patch that locks down kprobes in this
series.  Steven says that ftrace might acquire the ability to dump registers
in the future.

David