Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

[Wanpeng Li]

2017-08-16 17:25 GMT+08:00 Paolo Bonzini :
> On 16/08/2017 03:58, Lan Tianyu wrote:
>> These CR3 VMEXITs was introduced for platform without "unrestricted guest"
>> support. This is to set ept identity table to guest CR3 in guest real
>> mode because these platforms don't support ept real mode(CR0.PE and CR0.PG
>> must be set to 1). But these VMEXITs is redundant for platforms with
>> "unrestricted guest" support.
>
> This is true, but I'm not sure it's a good idea to make things more
> complex...  It is working code and is not a bottleneck anywhere.

Sorry, I have another question. There is no A20 emulation in kvm
currently, then whether or not the vm8086 which is emulated by kvm can
guarantee real mode guest which access occurs at 1 MByte will incur
address-wraparound?

Regards,
Wanpeng Li

>
> Paolo
>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/vmx.c | 22 +-
>>  1 file changed, 13 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 9b21b12..46dcf50 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -4221,18 +4221,20 @@ static void ept_update_paging_mode_cr0(unsigned long 
>> *hw_cr0,
>>   vmx_decache_cr3(vcpu);
>>   if (!(cr0 & X86_CR0_PG)) {
>>   /* From paging/starting to nonpaging */
>> - vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> -  vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) |
>> -  (CPU_BASED_CR3_LOAD_EXITING |
>> -   CPU_BASED_CR3_STORE_EXITING));
>> + if (!enable_unrestricted_guest)
>> + vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> +  vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) |
>> +  (CPU_BASED_CR3_LOAD_EXITING |
>> +   CPU_BASED_CR3_STORE_EXITING));
>>   vcpu->arch.cr0 = cr0;
>>   vmx_set_cr4(vcpu, kvm_read_cr4(vcpu));
>>   } else if (!is_paging(vcpu)) {
>>   /* From nonpaging to paging */
>> - vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> -  vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
>> -  ~(CPU_BASED_CR3_LOAD_EXITING |
>> -CPU_BASED_CR3_STORE_EXITING));
>> + if (!enable_unrestricted_guest)
>> + vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> +  vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
>> +  ~(CPU_BASED_CR3_LOAD_EXITING |
>> +CPU_BASED_CR3_STORE_EXITING));
>>   vcpu->arch.cr0 = cr0;
>>   vmx_set_cr4(vcpu, kvm_read_cr4(vcpu));
>>   }
>> @@ -4311,7 +4313,9 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, 
>> unsigned long cr3)
>>   }
>>
>>   vmx_flush_tlb(vcpu);
>> - vmcs_writel(GUEST_CR3, guest_cr3);
>> +
>> + if (!enable_unrestricted_guest || !enable_ept)
>> + vmcs_writel(GUEST_CR3, guest_cr3);
>>  }
>>
>>  static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
>>
>

Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

[Wanpeng Li]

2017-08-16 17:25 GMT+08:00 Paolo Bonzini :
> On 16/08/2017 03:58, Lan Tianyu wrote:
>> These CR3 VMEXITs was introduced for platform without "unrestricted guest"
>> support. This is to set ept identity table to guest CR3 in guest real
>> mode because these platforms don't support ept real mode(CR0.PE and CR0.PG
>> must be set to 1). But these VMEXITs is redundant for platforms with
>> "unrestricted guest" support.
>
> This is true, but I'm not sure it's a good idea to make things more
> complex...  It is working code and is not a bottleneck anywhere.

Sorry, I have another question. There is no A20 emulation in kvm
currently, then whether or not the vm8086 which is emulated by kvm can
guarantee real mode guest which access occurs at 1 MByte will incur
address-wraparound?

Regards,
Wanpeng Li

>
> Paolo
>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/vmx.c | 22 +-
>>  1 file changed, 13 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 9b21b12..46dcf50 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -4221,18 +4221,20 @@ static void ept_update_paging_mode_cr0(unsigned long 
>> *hw_cr0,
>>   vmx_decache_cr3(vcpu);
>>   if (!(cr0 & X86_CR0_PG)) {
>>   /* From paging/starting to nonpaging */
>> - vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> -  vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) |
>> -  (CPU_BASED_CR3_LOAD_EXITING |
>> -   CPU_BASED_CR3_STORE_EXITING));
>> + if (!enable_unrestricted_guest)
>> + vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> +  vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) |
>> +  (CPU_BASED_CR3_LOAD_EXITING |
>> +   CPU_BASED_CR3_STORE_EXITING));
>>   vcpu->arch.cr0 = cr0;
>>   vmx_set_cr4(vcpu, kvm_read_cr4(vcpu));
>>   } else if (!is_paging(vcpu)) {
>>   /* From nonpaging to paging */
>> - vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> -  vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
>> -  ~(CPU_BASED_CR3_LOAD_EXITING |
>> -CPU_BASED_CR3_STORE_EXITING));
>> + if (!enable_unrestricted_guest)
>> + vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> +  vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
>> +  ~(CPU_BASED_CR3_LOAD_EXITING |
>> +CPU_BASED_CR3_STORE_EXITING));
>>   vcpu->arch.cr0 = cr0;
>>   vmx_set_cr4(vcpu, kvm_read_cr4(vcpu));
>>   }
>> @@ -4311,7 +4313,9 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, 
>> unsigned long cr3)
>>   }
>>
>>   vmx_flush_tlb(vcpu);
>> - vmcs_writel(GUEST_CR3, guest_cr3);
>> +
>> + if (!enable_unrestricted_guest || !enable_ept)
>> + vmcs_writel(GUEST_CR3, guest_cr3);
>>  }
>>
>>  static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
>>
>

Re: [RFC PATCH 6/7] mmc: sdhci-omap: Add OMAP SDHCI driver

[Kishon Vijay Abraham I]

Hi Adrian,

On Tuesday 15 August 2017 01:52 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> Create a new sdhci-omap driver to configure the eMMC/SD/SDIO controller
>> in TI's OMAP SoCs making use of the SDHCI core library. For OMAP specific
>> configurations, populate sdhci_ops with OMAP specific callbacks and use
>> SDHCI quirks.
>> Enable only high speed mode for both SD and eMMC here and add other
>> UHS mode support later.
> 
> I only have a couple of comments below.
> 
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/mmc/host/Kconfig  |  12 +
>>  drivers/mmc/host/Makefile |   1 +
>>  drivers/mmc/host/sdhci-omap.c | 593 
>> ++
>>  3 files changed, 606 insertions(+)
>>  create mode 100644 drivers/mmc/host/sdhci-omap.c
>>
>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>> index 5755b69f2f72..9aa7e5ce43ba 100644
>> --- a/drivers/mmc/host/Kconfig
>> +++ b/drivers/mmc/host/Kconfig
>> @@ -871,3 +871,15 @@ config MMC_SDHCI_XENON
>>This selects Marvell Xenon eMMC/SD/SDIO SDHCI.
>>If you have a controller with this interface, say Y or M here.
>>If unsure, say N.
>> +
>> +config MMC_SDHCI_OMAP
>> +tristate "TI SDHCI Controller Support"
>> +depends on MMC_SDHCI_PLTFM
>> +help
>> +  This selects the Secure Digital Host Controller Interface (SDHCI)
>> +  support present in TI's DRA7 SOCs. The controller supports
>> +  SD/MMC/SDIO devices.
>> +
>> +  If you have a controller with this interface, say Y or M here.
>> +
>> +  If unsure, say N.
>> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
>> index 4d4547116311..30fb8b0fd0e1 100644
>> --- a/drivers/mmc/host/Makefile
>> +++ b/drivers/mmc/host/Makefile
>> @@ -82,6 +82,7 @@ obj-$(CONFIG_MMC_SDHCI_MSM)+= sdhci-msm.o
>>  obj-$(CONFIG_MMC_SDHCI_ST)  += sdhci-st.o
>>  obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32) += sdhci-pic32.o
>>  obj-$(CONFIG_MMC_SDHCI_BRCMSTB) += sdhci-brcmstb.o
>> +obj-$(CONFIG_MMC_SDHCI_OMAP)+= sdhci-omap.o
>>  
>>  ifeq ($(CONFIG_CB710_DEBUG),y)
>>  CFLAGS-cb710-mmc+= -DDEBUG
>> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
>> new file mode 100644
>> index ..c067c428a0cd
>> --- /dev/null
>> +++ b/drivers/mmc/host/sdhci-omap.c
>> @@ -0,0 +1,593 @@
>> +/*
>> + * SDHCI Controller driver for TI's OMAP SoCs
>> + *
>> + * Copyright (C) 2016-2017 Texas Instruments Incorporated - 
>> http://www.ti.com
>> + *
>> + * Authors: Kishon Vijay Abraham I 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "sdhci-pltfm.h"
>> +
>> +#define SDHCI_OMAP_CON  0x12c
>> +#define CON_DW8 BIT(5)
>> +#define CON_DMA_MASTER  BIT(20)
>> +#define CON_INITBIT(1)
>> +#define CON_OD  BIT(0)
>> +
>> +#define SDHCI_OMAP_CMD  0x20c
>> +
>> +#define SDHCI_OMAP_HCTL 0x228
>> +#define HCTL_SDBP   BIT(8)
>> +#define HCTL_SDVS_SHIFT 9
>> +#define HCTL_SDVS_MASK  (0x7 << HCTL_SDVS_SHIFT)
>> +#define HCTL_SDVS_33(0x7 << HCTL_SDVS_SHIFT)
>> +#define HCTL_SDVS_30(0x6 << HCTL_SDVS_SHIFT)
>> +#define HCTL_SDVS_18(0x5 << HCTL_SDVS_SHIFT)
>> +
>> +#define SDHCI_OMAP_SYSCTL   0x22c
>> +#define SYSCTL_CEN  BIT(2)
>> +#define SYSCTL_CLKD_SHIFT   6
>> +#define SYSCTL_CLKD_MASK0x3ff
>> +
>> +#define SDHCI_OMAP_STAT 0x230
>> +
>> +#define SDHCI_OMAP_IE   0x234
>> +#define INT_CC_EN   BIT(0)
>> +
>> +#define SDHCI_OMAP_AC12 0x23c
>> +#define AC12_V1V8_SIGEN BIT(19)
>> +
>> +#define SDHCI_OMAP_CAPA 0x240
>> +#define CAPA_VS33   BIT(24)
>> +#define CAPA_VS30   BIT(25)
>> +#define CAPA_VS18   BIT(26)
>> +
>> +#define MMC_TIMEOUT 1   /* 1 msec */
> 
> This name "MMC_TIMEOUT" is too generic.  SDHCI_OMAP_TIMEOUT would be better.

okay.
> 
>> +
>> +#define SYSCTL_CLKD_MAX 0x3FF
>> +
>> +#define IOV_1V8 180 /* 18 uV */
>> +#define IOV_3V0 300 /* 30 uV */
>> +#define IOV_3V3 330 /* 33 uV */
>> +
>> +struct sdhci_omap_data {
>> +u32 offset;
>> +};
>> +
>> +struct sdhci_omap_host {
>> +void __iomem*base;
>> +struct device   *dev;
>> +struct  regulator   *pbias;
>> +boolpbias_enabled;
>> +struct sdhci_host   *host;
>> 

Re: [RFC PATCH 6/7] mmc: sdhci-omap: Add OMAP SDHCI driver

[Kishon Vijay Abraham I]

Hi Adrian,

On Tuesday 15 August 2017 01:52 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> Create a new sdhci-omap driver to configure the eMMC/SD/SDIO controller
>> in TI's OMAP SoCs making use of the SDHCI core library. For OMAP specific
>> configurations, populate sdhci_ops with OMAP specific callbacks and use
>> SDHCI quirks.
>> Enable only high speed mode for both SD and eMMC here and add other
>> UHS mode support later.
> 
> I only have a couple of comments below.
> 
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/mmc/host/Kconfig  |  12 +
>>  drivers/mmc/host/Makefile |   1 +
>>  drivers/mmc/host/sdhci-omap.c | 593 
>> ++
>>  3 files changed, 606 insertions(+)
>>  create mode 100644 drivers/mmc/host/sdhci-omap.c
>>
>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>> index 5755b69f2f72..9aa7e5ce43ba 100644
>> --- a/drivers/mmc/host/Kconfig
>> +++ b/drivers/mmc/host/Kconfig
>> @@ -871,3 +871,15 @@ config MMC_SDHCI_XENON
>>This selects Marvell Xenon eMMC/SD/SDIO SDHCI.
>>If you have a controller with this interface, say Y or M here.
>>If unsure, say N.
>> +
>> +config MMC_SDHCI_OMAP
>> +tristate "TI SDHCI Controller Support"
>> +depends on MMC_SDHCI_PLTFM
>> +help
>> +  This selects the Secure Digital Host Controller Interface (SDHCI)
>> +  support present in TI's DRA7 SOCs. The controller supports
>> +  SD/MMC/SDIO devices.
>> +
>> +  If you have a controller with this interface, say Y or M here.
>> +
>> +  If unsure, say N.
>> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
>> index 4d4547116311..30fb8b0fd0e1 100644
>> --- a/drivers/mmc/host/Makefile
>> +++ b/drivers/mmc/host/Makefile
>> @@ -82,6 +82,7 @@ obj-$(CONFIG_MMC_SDHCI_MSM)+= sdhci-msm.o
>>  obj-$(CONFIG_MMC_SDHCI_ST)  += sdhci-st.o
>>  obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32) += sdhci-pic32.o
>>  obj-$(CONFIG_MMC_SDHCI_BRCMSTB) += sdhci-brcmstb.o
>> +obj-$(CONFIG_MMC_SDHCI_OMAP)+= sdhci-omap.o
>>  
>>  ifeq ($(CONFIG_CB710_DEBUG),y)
>>  CFLAGS-cb710-mmc+= -DDEBUG
>> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
>> new file mode 100644
>> index ..c067c428a0cd
>> --- /dev/null
>> +++ b/drivers/mmc/host/sdhci-omap.c
>> @@ -0,0 +1,593 @@
>> +/*
>> + * SDHCI Controller driver for TI's OMAP SoCs
>> + *
>> + * Copyright (C) 2016-2017 Texas Instruments Incorporated - 
>> http://www.ti.com
>> + *
>> + * Authors: Kishon Vijay Abraham I 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "sdhci-pltfm.h"
>> +
>> +#define SDHCI_OMAP_CON  0x12c
>> +#define CON_DW8 BIT(5)
>> +#define CON_DMA_MASTER  BIT(20)
>> +#define CON_INITBIT(1)
>> +#define CON_OD  BIT(0)
>> +
>> +#define SDHCI_OMAP_CMD  0x20c
>> +
>> +#define SDHCI_OMAP_HCTL 0x228
>> +#define HCTL_SDBP   BIT(8)
>> +#define HCTL_SDVS_SHIFT 9
>> +#define HCTL_SDVS_MASK  (0x7 << HCTL_SDVS_SHIFT)
>> +#define HCTL_SDVS_33(0x7 << HCTL_SDVS_SHIFT)
>> +#define HCTL_SDVS_30(0x6 << HCTL_SDVS_SHIFT)
>> +#define HCTL_SDVS_18(0x5 << HCTL_SDVS_SHIFT)
>> +
>> +#define SDHCI_OMAP_SYSCTL   0x22c
>> +#define SYSCTL_CEN  BIT(2)
>> +#define SYSCTL_CLKD_SHIFT   6
>> +#define SYSCTL_CLKD_MASK0x3ff
>> +
>> +#define SDHCI_OMAP_STAT 0x230
>> +
>> +#define SDHCI_OMAP_IE   0x234
>> +#define INT_CC_EN   BIT(0)
>> +
>> +#define SDHCI_OMAP_AC12 0x23c
>> +#define AC12_V1V8_SIGEN BIT(19)
>> +
>> +#define SDHCI_OMAP_CAPA 0x240
>> +#define CAPA_VS33   BIT(24)
>> +#define CAPA_VS30   BIT(25)
>> +#define CAPA_VS18   BIT(26)
>> +
>> +#define MMC_TIMEOUT 1   /* 1 msec */
> 
> This name "MMC_TIMEOUT" is too generic.  SDHCI_OMAP_TIMEOUT would be better.

okay.
> 
>> +
>> +#define SYSCTL_CLKD_MAX 0x3FF
>> +
>> +#define IOV_1V8 180 /* 18 uV */
>> +#define IOV_3V0 300 /* 30 uV */
>> +#define IOV_3V3 330 /* 33 uV */
>> +
>> +struct sdhci_omap_data {
>> +u32 offset;
>> +};
>> +
>> +struct sdhci_omap_host {
>> +void __iomem*base;
>> +struct device   *dev;
>> +struct  regulator   *pbias;
>> +boolpbias_enabled;
>> +struct sdhci_host   *host;
>> +unsigned int

Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s

[Alexander Stein]

On Wednesday 16 August 2017 17:15:55, Ken Goldman wrote:
> On 8/15/2017 4:13 PM, Haris Okanovic wrote:
> > ioread8() operations to TPM MMIO addresses can stall the cpu when
> > immediately following a sequence of iowrite*()'s to the same region.
> > 
> > For example, cyclitest measures ~400us latency spikes when a non-RT
> > usermode application communicates with an SPI-based TPM chip (Intel Atom
> > E3940 system, PREEMPT_RT_FULL kernel). The spikes are caused by a
> > stalling ioread8() operation following a sequence of 30+ iowrite8()s to
> > the same address. I believe this happens because the write sequence is
> > buffered (in cpu or somewhere along the bus), and gets flushed on the
> > first LOAD instruction (ioread*()) that follows.
> > 
> > The enclosed change appears to fix this issue: read the TPM chip's
> > access register (status code) after every iowrite*() operation to
> > amortize the cost of flushing data to chip across multiple instructions.
> 
> I worry a bit about "appears to fix".  It seems odd that the TPM device
> driver would be the first code to uncover this.  Can anyone confirm that
> the chipset does indeed have this bug?

No, there was already a similar problem in e1000e where a PCIe read stalled 
the CPU, hence no interrupts are serviced. See 
https://www.spinics.net/lists/linux-rt-users/msg14077.html
AFAIK there was no outcome though.

> I'd also like an indication of the performance penalty.  We're doing a
> lot of work to improve the performance and I worry that "do a read after
> every write" will have a performance impact.

Realtime will always affect performance, but IMHO the latter is much more 
important.

Best regards,
Alexander

Re: [PATCH 4.4 018/101] netfilter: synproxy: fix conntrackd interaction

[Stefan Bader]

On 03.07.2017 15:34, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.

We found that pulling below patch into stable trees without also pulling

commit 9c3f3794926a997b1cab6c42480ff300efa2d162
Author: Liping Zhang 
Date:   Sat Mar 25 16:35:29 2017 +0800

netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister

will result in a regression, at least in 4.4.y[1]. Stable maintainers who picked
up below patch might want to consider picking up above fix.

-Stefan


[1] http://bugs.launchpad.net/bugs/1709032
> 
> --
> 
> From: Eric Leblond 
> 
> commit 87e94dbc210a720a34be5c1174faee5c84be963e upstream.
> 
> This patch fixes the creation of connection tracking entry from
> netlink when synproxy is used. It was missing the addition of
> the synproxy extension.
> 
> This was causing kernel crashes when a conntrack entry created by
> conntrackd was used after the switch of traffic from active node
> to the passive node.
> 
> Signed-off-by: Eric Leblond 
> Signed-off-by: Pablo Neira Ayuso 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  net/netfilter/nf_conntrack_netlink.c |4 
>  1 file changed, 4 insertions(+)
> 
> --- a/net/netfilter/nf_conntrack_netlink.c
> +++ b/net/netfilter/nf_conntrack_netlink.c
> @@ -45,6 +45,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #ifdef CONFIG_NF_NAT_NEEDED
>  #include 
>  #include 
> @@ -1798,6 +1800,8 @@ ctnetlink_create_conntrack(struct net *n
>   nf_ct_tstamp_ext_add(ct, GFP_ATOMIC);
>   nf_ct_ecache_ext_add(ct, 0, 0, GFP_ATOMIC);
>   nf_ct_labels_ext_add(ct);
> + nfct_seqadj_ext_add(ct);
> + nfct_synproxy_ext_add(ct);
>  
>   /* we must add conntrack extensions before confirmation. */
>   ct->status |= IPS_CONFIRMED;
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: [tpmdd-devel] [PATCH v2] tpm_tis: fix stall after iowrite*()s

[Alexander Stein]

On Wednesday 16 August 2017 17:15:55, Ken Goldman wrote:
> On 8/15/2017 4:13 PM, Haris Okanovic wrote:
> > ioread8() operations to TPM MMIO addresses can stall the cpu when
> > immediately following a sequence of iowrite*()'s to the same region.
> > 
> > For example, cyclitest measures ~400us latency spikes when a non-RT
> > usermode application communicates with an SPI-based TPM chip (Intel Atom
> > E3940 system, PREEMPT_RT_FULL kernel). The spikes are caused by a
> > stalling ioread8() operation following a sequence of 30+ iowrite8()s to
> > the same address. I believe this happens because the write sequence is
> > buffered (in cpu or somewhere along the bus), and gets flushed on the
> > first LOAD instruction (ioread*()) that follows.
> > 
> > The enclosed change appears to fix this issue: read the TPM chip's
> > access register (status code) after every iowrite*() operation to
> > amortize the cost of flushing data to chip across multiple instructions.
> 
> I worry a bit about "appears to fix".  It seems odd that the TPM device
> driver would be the first code to uncover this.  Can anyone confirm that
> the chipset does indeed have this bug?

No, there was already a similar problem in e1000e where a PCIe read stalled 
the CPU, hence no interrupts are serviced. See 
https://www.spinics.net/lists/linux-rt-users/msg14077.html
AFAIK there was no outcome though.

> I'd also like an indication of the performance penalty.  We're doing a
> lot of work to improve the performance and I worry that "do a read after
> every write" will have a performance impact.

Realtime will always affect performance, but IMHO the latter is much more 
important.

Best regards,
Alexander

Re: [PATCH 4.4 018/101] netfilter: synproxy: fix conntrackd interaction

[Stefan Bader]

On 03.07.2017 15:34, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.

We found that pulling below patch into stable trees without also pulling

commit 9c3f3794926a997b1cab6c42480ff300efa2d162
Author: Liping Zhang 
Date:   Sat Mar 25 16:35:29 2017 +0800

netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister

will result in a regression, at least in 4.4.y[1]. Stable maintainers who picked
up below patch might want to consider picking up above fix.

-Stefan


[1] http://bugs.launchpad.net/bugs/1709032
> 
> --
> 
> From: Eric Leblond 
> 
> commit 87e94dbc210a720a34be5c1174faee5c84be963e upstream.
> 
> This patch fixes the creation of connection tracking entry from
> netlink when synproxy is used. It was missing the addition of
> the synproxy extension.
> 
> This was causing kernel crashes when a conntrack entry created by
> conntrackd was used after the switch of traffic from active node
> to the passive node.
> 
> Signed-off-by: Eric Leblond 
> Signed-off-by: Pablo Neira Ayuso 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  net/netfilter/nf_conntrack_netlink.c |4 
>  1 file changed, 4 insertions(+)
> 
> --- a/net/netfilter/nf_conntrack_netlink.c
> +++ b/net/netfilter/nf_conntrack_netlink.c
> @@ -45,6 +45,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #ifdef CONFIG_NF_NAT_NEEDED
>  #include 
>  #include 
> @@ -1798,6 +1800,8 @@ ctnetlink_create_conntrack(struct net *n
>   nf_ct_tstamp_ext_add(ct, GFP_ATOMIC);
>   nf_ct_ecache_ext_add(ct, 0, 0, GFP_ATOMIC);
>   nf_ct_labels_ext_add(ct);
> + nfct_seqadj_ext_add(ct);
> + nfct_synproxy_ext_add(ct);
>  
>   /* we must add conntrack extensions before confirmation. */
>   ct->status |= IPS_CONFIRMED;
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: [RFC][PATCHv5 06/13] printk: register PM notifier

[Sergey Senozhatsky]

Hello Rafael,

On (08/16/17 14:58), Rafael J. Wysocki wrote:
[..]
> > hm, those two are interesting questions. in short - well, it might
> > be. I don't want to interfere with PM by doing 'accidental' offloading
> > etc., PM is too complicated already. so I'd prefer to switch to old
> > printk behavior early (besides, I tend to see lockups reports more
> > often when the kernel is up and running, rather than during PM events.)
> > but, once again, may be it is too early and we can move emergency_mode
> > switch.
> 
> Well, that depends on what your goal is really.

to avoid any PM breakage :)

> I thought you wanted to do the offloading as far into the suspend as it
> was safe to do (and analogously for resume), but now I see you want to
> stop doing it as early as it makes sense. :-)

ideally yes :) but in reality I'd probably prefer to switch to emergency
printk ASAP during PM. we have reports of broken PM because of offloading
from Linaro (well... a long time ago, and printk kthread patch set was
completely different back then).

> In that case I would call printk_emergency_begin_sync() from
> dpm_prepare() and printk_emergency_end_sync() from dpm_complete().

hm, isn't it the case that dpm_prepare/dpm_complete are invoked only
by hibernate path? or does suspend path (s2ram, etc.) also calls
dpm_prepare/dpm_complete?

the 3 things we need to have (in PM context) for offloading:
- unparked printk kthread
- running scheduler
- online non-boot CPUs (on a UP system, or with non-boot CPUs disabled,
  offloading is a bit questionable)

- hm, may be something else...

[..]
> > we didn't want to spread printk_emergency_{begin, end}
> > calls across the kernel.
> 
> But this adds one invocation of each of them anyway *plus* some
> extra code around those.  Wouldn't it be cleaner to add those
> invocations alone?
[..]
> I just don't see much point in using the notifier thing if you can
> achieve basically the same without using it. :-)

sure, I just didn't want to mix printk internals with PM internals.
that would put us in position of verifying future PM changes from
printk-kthread point of view as well; and it can be quite complex,
because printk offloading brings in big guns like scheduler and
timekeeping. so the notifiers interface looks like a good
alternative, besides those notifications happen early (and late)
enough to keep us on the safe side.

well, I may be wrong.

-ss

Re: [RFC][PATCHv5 06/13] printk: register PM notifier

[Sergey Senozhatsky]

Hello Rafael,

On (08/16/17 14:58), Rafael J. Wysocki wrote:
[..]
> > hm, those two are interesting questions. in short - well, it might
> > be. I don't want to interfere with PM by doing 'accidental' offloading
> > etc., PM is too complicated already. so I'd prefer to switch to old
> > printk behavior early (besides, I tend to see lockups reports more
> > often when the kernel is up and running, rather than during PM events.)
> > but, once again, may be it is too early and we can move emergency_mode
> > switch.
> 
> Well, that depends on what your goal is really.

to avoid any PM breakage :)

> I thought you wanted to do the offloading as far into the suspend as it
> was safe to do (and analogously for resume), but now I see you want to
> stop doing it as early as it makes sense. :-)

ideally yes :) but in reality I'd probably prefer to switch to emergency
printk ASAP during PM. we have reports of broken PM because of offloading
from Linaro (well... a long time ago, and printk kthread patch set was
completely different back then).

> In that case I would call printk_emergency_begin_sync() from
> dpm_prepare() and printk_emergency_end_sync() from dpm_complete().

hm, isn't it the case that dpm_prepare/dpm_complete are invoked only
by hibernate path? or does suspend path (s2ram, etc.) also calls
dpm_prepare/dpm_complete?

the 3 things we need to have (in PM context) for offloading:
- unparked printk kthread
- running scheduler
- online non-boot CPUs (on a UP system, or with non-boot CPUs disabled,
  offloading is a bit questionable)

- hm, may be something else...

[..]
> > we didn't want to spread printk_emergency_{begin, end}
> > calls across the kernel.
> 
> But this adds one invocation of each of them anyway *plus* some
> extra code around those.  Wouldn't it be cleaner to add those
> invocations alone?
[..]
> I just don't see much point in using the notifier thing if you can
> achieve basically the same without using it. :-)

sure, I just didn't want to mix printk internals with PM internals.
that would put us in position of verifying future PM changes from
printk-kthread point of view as well; and it can be quite complex,
because printk offloading brings in big guns like scheduler and
timekeeping. so the notifiers interface looks like a good
alternative, besides those notifications happen early (and late)
enough to keep us on the safe side.

well, I may be wrong.

-ss

Re: [RFC PATCH 5/7] dt-bindings: ti-omap-hsmmc: Document new compatible for sdhci omap

[Kishon Vijay Abraham I]

Hi Tony,

On Thursday 10 August 2017 03:42 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I  [170807 09:03]:
>> Document the new compatible string "ti,dra7-sdhci" to be used for
>> MMC controllers in DRA7 and DRA72 SoCs.
> 
> I wonder if this should really be documented for sdhci
> instead of ti-omap-hsmmc.txt?

hmm.. yeah, having a separate binding document for sdhci would make the binding
really clean and we also don't have to carry legacy binding code. But we'll be
never able to remove omap-hsmmc driver then and end up maintaining 2 drivers
for the same controller.
> 
> I agree it's better to use sdhci compatible and keep the
> hsmmc compatible around as the sdhci is still missing features
> for runtime PM and context save and restore etc.

yeah, once we have all the features in omap_hsmmc added in sdhci-omap, we can
add the omap-hsmmc compatible to sdhci-omap and remove omap-hsmmc driver.

Thanks
Kishon

Re: [RFC PATCH 5/7] dt-bindings: ti-omap-hsmmc: Document new compatible for sdhci omap

[Kishon Vijay Abraham I]

Hi Tony,

On Thursday 10 August 2017 03:42 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I  [170807 09:03]:
>> Document the new compatible string "ti,dra7-sdhci" to be used for
>> MMC controllers in DRA7 and DRA72 SoCs.
> 
> I wonder if this should really be documented for sdhci
> instead of ti-omap-hsmmc.txt?

hmm.. yeah, having a separate binding document for sdhci would make the binding
really clean and we also don't have to carry legacy binding code. But we'll be
never able to remove omap-hsmmc driver then and end up maintaining 2 drivers
for the same controller.
> 
> I agree it's better to use sdhci compatible and keep the
> hsmmc compatible around as the sdhci is still missing features
> for runtime PM and context save and restore etc.

yeah, once we have all the features in omap_hsmmc added in sdhci-omap, we can
add the omap-hsmmc compatible to sdhci-omap and remove omap-hsmmc driver.

Thanks
Kishon

Re: [RFC PATCH 4/7] mmc: sdhci: Add quirk to indicate broken POWER_CONTROL

[Kishon Vijay Abraham I]

On Tuesday 15 August 2017 01:11 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> TI's implementation of sdhci controller used in DRA7 SoC's uses
>> POWER_CONTROL register for configuring IO voltage and not
>> for core voltage (vdd) which is it's intended use. Add a quirk
>> to indicate broken POWER_CONTROL register.
> 
> A quirk isn't needed for this.  Use the ->set_power() callback instead.

sure!

Thanks
Kishon
> 
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/mmc/host/sdhci.c | 6 ++
>>  drivers/mmc/host/sdhci.h | 2 ++
>>  2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index d5050ec42481..a7465a56e6b5 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1419,6 +1419,9 @@ static void sdhci_set_power_reg(struct sdhci_host 
>> *host, unsigned char mode,
>>  
>>  mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
>>  
>> +if (host->quirks2 & SDHCI_QUIRK2_BROKEN_POWER_CONTROL)
>> +return;
>> +
>>  if (mode != MMC_POWER_OFF)
>>  sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
>>  else
>> @@ -1430,6 +1433,9 @@ void sdhci_set_power_noreg(struct sdhci_host *host, 
>> unsigned char mode,
>>  {
>>  u8 pwr = 0;
>>  
>> +if (host->quirks2 & SDHCI_QUIRK2_BROKEN_POWER_CONTROL)
>> +return;
>> +
>>  if (mode != MMC_POWER_OFF) {
>>  switch (1 << vdd) {
>>  case MMC_VDD_165_195:
>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>> index 39c7a2723906..ba94cca7c892 100644
>> --- a/drivers/mmc/host/sdhci.h
>> +++ b/drivers/mmc/host/sdhci.h
>> @@ -439,6 +439,8 @@ struct sdhci_host {
>>  #define SDHCI_QUIRK2_NO_CRC_STRIPPING   (1<<16)
>>  /* Controller has bad caps bits, but really supports DMA */
>>  #define SDHCI_QUIRK2_FORCE_ADMA (1<<17)
>> +/* Controller uses POWER_CONTROL for managing IO voltage and not core 
>> voltage */
>> +#define SDHCI_QUIRK2_BROKEN_POWER_CONTROL   (1<<18)
>>  
>>  int irq;/* Device IRQ */
>>  void __iomem *ioaddr;   /* Mapped address */
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC PATCH 4/7] mmc: sdhci: Add quirk to indicate broken POWER_CONTROL

[Kishon Vijay Abraham I]

On Tuesday 15 August 2017 01:11 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> TI's implementation of sdhci controller used in DRA7 SoC's uses
>> POWER_CONTROL register for configuring IO voltage and not
>> for core voltage (vdd) which is it's intended use. Add a quirk
>> to indicate broken POWER_CONTROL register.
> 
> A quirk isn't needed for this.  Use the ->set_power() callback instead.

sure!

Thanks
Kishon
> 
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/mmc/host/sdhci.c | 6 ++
>>  drivers/mmc/host/sdhci.h | 2 ++
>>  2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index d5050ec42481..a7465a56e6b5 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1419,6 +1419,9 @@ static void sdhci_set_power_reg(struct sdhci_host 
>> *host, unsigned char mode,
>>  
>>  mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
>>  
>> +if (host->quirks2 & SDHCI_QUIRK2_BROKEN_POWER_CONTROL)
>> +return;
>> +
>>  if (mode != MMC_POWER_OFF)
>>  sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
>>  else
>> @@ -1430,6 +1433,9 @@ void sdhci_set_power_noreg(struct sdhci_host *host, 
>> unsigned char mode,
>>  {
>>  u8 pwr = 0;
>>  
>> +if (host->quirks2 & SDHCI_QUIRK2_BROKEN_POWER_CONTROL)
>> +return;
>> +
>>  if (mode != MMC_POWER_OFF) {
>>  switch (1 << vdd) {
>>  case MMC_VDD_165_195:
>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>> index 39c7a2723906..ba94cca7c892 100644
>> --- a/drivers/mmc/host/sdhci.h
>> +++ b/drivers/mmc/host/sdhci.h
>> @@ -439,6 +439,8 @@ struct sdhci_host {
>>  #define SDHCI_QUIRK2_NO_CRC_STRIPPING   (1<<16)
>>  /* Controller has bad caps bits, but really supports DMA */
>>  #define SDHCI_QUIRK2_FORCE_ADMA (1<<17)
>> +/* Controller uses POWER_CONTROL for managing IO voltage and not core 
>> voltage */
>> +#define SDHCI_QUIRK2_BROKEN_POWER_CONTROL   (1<<18)
>>  
>>  int irq;/* Device IRQ */
>>  void __iomem *ioaddr;   /* Mapped address */
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC PATCH 3/7] mmc: sdhci: Add callback to set bus mode

[Kishon Vijay Abraham I]

Adrian,

On Tuesday 15 August 2017 01:08 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> Add callback to set bus mode in sdhci library so that the
>> controller driver can perform any bus mode specific configurations
>> in the callback function.
> 
> A quirk isn't needed.  Just hook ->set_ios() e.g.
> 
>   host->mmc_host_ops.set_ios = sdhci_omap_set_ios;
> 
> Then sdhci_omap_set_ios() can call sdhci_set_ios() and then do the bus mode
> setting.

I'm not adding a quirk here.. but I got your point.

Thanks
Kishon

Re: [RFC PATCH 3/7] mmc: sdhci: Add callback to set bus mode

[Kishon Vijay Abraham I]

Adrian,

On Tuesday 15 August 2017 01:08 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> Add callback to set bus mode in sdhci library so that the
>> controller driver can perform any bus mode specific configurations
>> in the callback function.
> 
> A quirk isn't needed.  Just hook ->set_ios() e.g.
> 
>   host->mmc_host_ops.set_ios = sdhci_omap_set_ios;
> 
> Then sdhci_omap_set_ios() can call sdhci_set_ios() and then do the bus mode
> setting.

I'm not adding a quirk here.. but I got your point.

Thanks
Kishon

Re: [PATCH] zsmalloc: zs_page_isolate: skip unnecessary loops but not return false if zspage is not inuse

[Minchan Kim]

On Wed, Aug 16, 2017 at 03:49:54PM +0800, Hui Zhu wrote:
> Like [1], zs_page_isolate meet the same problem if zspage is not inuse.
> 
> After [2], zs_page_migrate can support empty zspage now.
> 
> Make this patch to let zs_page_isolate skip unnecessary loops but not
> return false if zspage is not inuse.
> 
> [1] 
> zsmalloc-zs_page_migrate-skip-unnecessary-loops-but-not-return-ebusy-if-zspage-is-not-inuse-fix.patch
> [2] zsmalloc-zs_page_migrate-schedule-free_work-if-zspage-is-ZS_EMPTY.patch
> 
> Signed-off-by: Hui Zhu 
Acked-by: Minchan Kim 

Andrew,
Could you fold this to 
zsmalloc-zs_page_migrate-skip-unnecessary-loops-but-not-return-ebusy-if-zspage-is-not-inuse?

Thanks!

Re: [PATCH] zsmalloc: zs_page_isolate: skip unnecessary loops but not return false if zspage is not inuse

[Minchan Kim]

On Wed, Aug 16, 2017 at 03:49:54PM +0800, Hui Zhu wrote:
> Like [1], zs_page_isolate meet the same problem if zspage is not inuse.
> 
> After [2], zs_page_migrate can support empty zspage now.
> 
> Make this patch to let zs_page_isolate skip unnecessary loops but not
> return false if zspage is not inuse.
> 
> [1] 
> zsmalloc-zs_page_migrate-skip-unnecessary-loops-but-not-return-ebusy-if-zspage-is-not-inuse-fix.patch
> [2] zsmalloc-zs_page_migrate-schedule-free_work-if-zspage-is-ZS_EMPTY.patch
> 
> Signed-off-by: Hui Zhu 
Acked-by: Minchan Kim 

Andrew,
Could you fold this to 
zsmalloc-zs_page_migrate-skip-unnecessary-loops-but-not-return-ebusy-if-zspage-is-not-inuse?

Thanks!

Re: [RFC PATCH 2/7] mmc: sdhci: Add quirk to indicate controller supports ADMA2

[Kishon Vijay Abraham I]

On Tuesday 15 August 2017 01:03 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> TI's implementation of sdhci controller used in DRA7 SoC's doesn't
>> have SDHCI_CAN_DO_ADMA2 set in CAPA register though it supports
>> ADMA2. Add quirk to support using ADMA2 even if the controller reports
>> incorrect capability in CAPA.
> 
> A quirk is not needed for this.  Just call sdhci_read_caps() and change
> host->caps before calling sdhci_add_host().

Okay, got it.

Thanks
Kishon
> 
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/mmc/host/sdhci.c | 3 ++-
>>  drivers/mmc/host/sdhci.h | 2 ++
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index ece3751d2a25..fff0baadbc3e 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -3264,7 +3264,8 @@ int sdhci_setup_host(struct sdhci_host *host)
>>  }
>>  
>>  if ((host->version >= SDHCI_SPEC_200) &&
>> -(host->caps & SDHCI_CAN_DO_ADMA2))
>> +((host->caps & SDHCI_CAN_DO_ADMA2) ||
>> +(host->quirks2 & SDHCI_QUIRK2_FORCE_ADMA)))
>>  host->flags |= SDHCI_USE_ADMA;
>>  
>>  if ((host->quirks & SDHCI_QUIRK_BROKEN_ADMA) &&
>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>> index 6905131f603d..d778034e324d 100644
>> --- a/drivers/mmc/host/sdhci.h
>> +++ b/drivers/mmc/host/sdhci.h
>> @@ -437,6 +437,8 @@ struct sdhci_host {
>>  #define SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN  (1<<15)
>>  /* Controller does not have CRC stripped in Command Response */
>>  #define SDHCI_QUIRK2_NO_CRC_STRIPPING   (1<<16)
>> +/* Controller has bad caps bits, but really supports DMA */
>> +#define SDHCI_QUIRK2_FORCE_ADMA (1<<17)
>>  
>>  int irq;/* Device IRQ */
>>  void __iomem *ioaddr;   /* Mapped address */
>>
> 

Re: [RFC PATCH 2/7] mmc: sdhci: Add quirk to indicate controller supports ADMA2

[Kishon Vijay Abraham I]

On Tuesday 15 August 2017 01:03 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> TI's implementation of sdhci controller used in DRA7 SoC's doesn't
>> have SDHCI_CAN_DO_ADMA2 set in CAPA register though it supports
>> ADMA2. Add quirk to support using ADMA2 even if the controller reports
>> incorrect capability in CAPA.
> 
> A quirk is not needed for this.  Just call sdhci_read_caps() and change
> host->caps before calling sdhci_add_host().

Okay, got it.

Thanks
Kishon
> 
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/mmc/host/sdhci.c | 3 ++-
>>  drivers/mmc/host/sdhci.h | 2 ++
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index ece3751d2a25..fff0baadbc3e 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -3264,7 +3264,8 @@ int sdhci_setup_host(struct sdhci_host *host)
>>  }
>>  
>>  if ((host->version >= SDHCI_SPEC_200) &&
>> -(host->caps & SDHCI_CAN_DO_ADMA2))
>> +((host->caps & SDHCI_CAN_DO_ADMA2) ||
>> +(host->quirks2 & SDHCI_QUIRK2_FORCE_ADMA)))
>>  host->flags |= SDHCI_USE_ADMA;
>>  
>>  if ((host->quirks & SDHCI_QUIRK_BROKEN_ADMA) &&
>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>> index 6905131f603d..d778034e324d 100644
>> --- a/drivers/mmc/host/sdhci.h
>> +++ b/drivers/mmc/host/sdhci.h
>> @@ -437,6 +437,8 @@ struct sdhci_host {
>>  #define SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN  (1<<15)
>>  /* Controller does not have CRC stripped in Command Response */
>>  #define SDHCI_QUIRK2_NO_CRC_STRIPPING   (1<<16)
>> +/* Controller has bad caps bits, but really supports DMA */
>> +#define SDHCI_QUIRK2_FORCE_ADMA (1<<17)
>>  
>>  int irq;/* Device IRQ */
>>  void __iomem *ioaddr;   /* Mapped address */
>>
> 

Re: [RFC PATCH 1/7] mmc: sdhci: Add quirk to indicate no CRC stripping in MMC_RSP_136

[Kishon Vijay Abraham I]

Hi Adrian,

On Tuesday 15 August 2017 12:57 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> TI's implementation of sdhci controller used in DRA7 SoC's doesn't
>> strip CRC in responses with length 136 bits. Add quirk to indicate
>> the controller does not strip CRC in MMC_RSP_136. If this quirk is
>> set sdhci library shouldn't shift the response present in
>> SDHCI_RESPONSE register.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/mmc/host/sdhci.c | 27 +++
>>  drivers/mmc/host/sdhci.h |  2 ++
>>  2 files changed, 21 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index ecd0d4350e8a..ece3751d2a25 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1182,14 +1182,25 @@ static void sdhci_finish_command(struct sdhci_host 
>> *host)
>>  
>>  if (cmd->flags & MMC_RSP_PRESENT) {
>>  if (cmd->flags & MMC_RSP_136) {
>> -/* CRC is stripped so we need to do some shifting. */
>> -for (i = 0;i < 4;i++) {
>> -cmd->resp[i] = sdhci_readl(host,
>> -SDHCI_RESPONSE + (3-i)*4) << 8;
>> -if (i != 3)
>> -cmd->resp[i] |=
>> -sdhci_readb(host,
>> -SDHCI_RESPONSE + (3-i)*4-1);
>> +if (!(host->quirks2 & SDHCI_QUIRK2_NO_CRC_STRIPPING)) {
> 
> This is about the 136-bit response so let's put that in the quirk name.  How 
> about SDHCI_QUIRK2_RSP_136_HAS_CRC

Since omap seems to be the only platform that doesn't have CRC, I prefer adding
SDHCI_QUIRK2_RSP_136_NO_CRC. That way we can add the quirk only in sdhci-omap
instead of all the existing sdhci drivers.

> 
>> +/*
>> + * CRC is stripped so we need to do some
>> + * shifting.
>> + */
>> +for (i = 0; i < 4; i++) {
>> +cmd->resp[i] =
>> +sdhci_readl(host, SDHCI_RESPONSE
>> ++ (3 - i) * 4) << 8;
>> +if (i != 3)
>> +cmd->resp[i] |=
>> +sdhci_readb(host, SDHCI_RESPONSE
>> ++ (3 - i) * 4 - 1);
>> +}
>> +} else {
>> +for (i = 0; i < 4; i++)
>> +cmd->resp[i] =
>> +sdhci_readl(host, SDHCI_RESPONSE +
>> +(3 - i) * 4);
>>  }
> 
> This is all very jammed up against the 80 column margin.  Please make a new 
> patch to separate it into a new function sdhci_read_rsp_136() and then 
> another patch to add the quirk.
> i.e. completely untested!

Sure. Thanks for the patch.

Thanks
Kishon

Re: [RFC PATCH 1/7] mmc: sdhci: Add quirk to indicate no CRC stripping in MMC_RSP_136

[Kishon Vijay Abraham I]

Hi Adrian,

On Tuesday 15 August 2017 12:57 PM, Adrian Hunter wrote:
> On 07/08/17 19:01, Kishon Vijay Abraham I wrote:
>> TI's implementation of sdhci controller used in DRA7 SoC's doesn't
>> strip CRC in responses with length 136 bits. Add quirk to indicate
>> the controller does not strip CRC in MMC_RSP_136. If this quirk is
>> set sdhci library shouldn't shift the response present in
>> SDHCI_RESPONSE register.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  drivers/mmc/host/sdhci.c | 27 +++
>>  drivers/mmc/host/sdhci.h |  2 ++
>>  2 files changed, 21 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index ecd0d4350e8a..ece3751d2a25 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1182,14 +1182,25 @@ static void sdhci_finish_command(struct sdhci_host 
>> *host)
>>  
>>  if (cmd->flags & MMC_RSP_PRESENT) {
>>  if (cmd->flags & MMC_RSP_136) {
>> -/* CRC is stripped so we need to do some shifting. */
>> -for (i = 0;i < 4;i++) {
>> -cmd->resp[i] = sdhci_readl(host,
>> -SDHCI_RESPONSE + (3-i)*4) << 8;
>> -if (i != 3)
>> -cmd->resp[i] |=
>> -sdhci_readb(host,
>> -SDHCI_RESPONSE + (3-i)*4-1);
>> +if (!(host->quirks2 & SDHCI_QUIRK2_NO_CRC_STRIPPING)) {
> 
> This is about the 136-bit response so let's put that in the quirk name.  How 
> about SDHCI_QUIRK2_RSP_136_HAS_CRC

Since omap seems to be the only platform that doesn't have CRC, I prefer adding
SDHCI_QUIRK2_RSP_136_NO_CRC. That way we can add the quirk only in sdhci-omap
instead of all the existing sdhci drivers.

> 
>> +/*
>> + * CRC is stripped so we need to do some
>> + * shifting.
>> + */
>> +for (i = 0; i < 4; i++) {
>> +cmd->resp[i] =
>> +sdhci_readl(host, SDHCI_RESPONSE
>> ++ (3 - i) * 4) << 8;
>> +if (i != 3)
>> +cmd->resp[i] |=
>> +sdhci_readb(host, SDHCI_RESPONSE
>> ++ (3 - i) * 4 - 1);
>> +}
>> +} else {
>> +for (i = 0; i < 4; i++)
>> +cmd->resp[i] =
>> +sdhci_readl(host, SDHCI_RESPONSE +
>> +(3 - i) * 4);
>>  }
> 
> This is all very jammed up against the 80 column margin.  Please make a new 
> patch to separate it into a new function sdhci_read_rsp_136() and then 
> another patch to add the quirk.
> i.e. completely untested!

Sure. Thanks for the patch.

Thanks
Kishon

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

[Benjamin Herrenschmidt]

On Wed, 2017-08-16 at 10:56 -0600, Alex Williamson wrote:
> 
> > WTF  Alex, can you stop once and for all with all that "POWER is
> > not standard" bullshit please ? It's completely wrong.
> 
> As you've stated, the MSI-X vector table on POWER is currently updated
> via a hypercall.  POWER is overall PCI compliant (I assume), but the
> guest does not directly modify the vector table in MMIO space of the
> device.  This is important...

Well no. On qemu the guest doesn't always (but it can save/restore it),
but on PowerVM this is done by the FW running inside the partition
itself. And that firmware just does normal stores to the device table.

IE. The problem here isn't so much who does the actual stores to the
device table but where they get the address and data values from, which
isn't covered by the spec.

The added fact that qemu hijacks the stores not just to "remap" them
but also do the whole reuqesting of the interrupt etc... in the host
system is a qemu design choice which also hasn't any relation to the
spec (and arguably isnt' a great choice for our systems).

For example, on PowerVM, the HV assigns a pile of MSIs to the guest to
assign to its devices. The FW inside the guest does a default
assignment but that can be changed.

Thus the interrupts are effectively "hooked up" at the HV level at the
point where the PCI bridge is mapped into the guest.

> > This has nothing to do with PCIe standard !
> 
> Yes, it actually does, because if the guest relies on the vector table
> to be virtualized then it doesn't particularly matter whether the
> vfio-pci kernel driver allows that portion of device MMIO space to be
> directly accessed or mapped because QEMU needs for it to be trapped in
> order to provide that virtualization.

And this has nothing to do with the PCIe standard... this has
everything to do with a combination of qemu design choices and
defficient FW interfaces on x86 platforms.

> I'm not knocking POWER, it's a smart thing for virtualization to have
> defined this hypercall which negates the need for vector table
> virtualization and allows efficient mapping of the device.  On other
> platform, it's not necessarily practical given the broad base of legacy
> guests supported where we'd never get agreement to implement this as
> part of the platform spec... if there even was such a thing.  Maybe we
> could provide the hypercall and dynamically enable direct vector table
> mapping (disabling vector table virtualization) only if the hypercall
> is used.

No I think a better approach would be to provide the guest with a pile
of MSIs to use with devices and have FW (such as ACPI) tell the guest
about them.

> > The PCIe standard says strictly *nothing* whatsoever about how an OS
> > obtains the magic address/values to put in the device and how the PCIe
> > host bridge may do appropriate fitering.
> 
> And now we've jumped the tracks...  The only way the platform specific
> address/data values become important is if we allow direct access to
> the vector table AND now we're formulating how the user/guest might
> write to it directly.  Otherwise the virtualization of the vector
> table, or paravirtualization via hypercall provides the translation
> where the host and guest address/data pairs can operate in completely
> different address spaces.

They can regardless if things are done properly :-)

> > There is nothing on POWER that prevents the guest from writing the MSI-
> > X address/data by hand. The problem isn't who writes the values or even
> > how. The problem breaks down into these two things that are NOT covered
> > by any aspect of the PCIe standard:
> 
> You've moved on to a different problem, I think everyone aside from
> POWER is still back at the problem where who writes the vector table
> values is a forefront problem.
>  
> >   1- The OS needs to obtain address/data values for an MSI that will
> > "work" for the device.
> > 
> >   2- The HW+HV needs to prevent collateral damage caused by a device
> > issuing stores to incorrect address or with incorrect data. Now *this*
> > is necessary for *ANY* kind of DMA whether it's an MSI or something
> > else anyway.
> > 
> > Now, the filtering done by qemu is NOT a reasonable way to handle 2)
> > and whatever excluse about "making it harder" doesn't fly a meter when
> > it comes to security. Making it "harder to break accidentally" I also
> > don't buy, people don't just randomly put things in their MSI-X tables
> > "accidentally", that stuff works or doesn't.
> 
> As I said before, I'm not willing to preserve the weak attributes that
> blocking direct vector table access provides over pursuing a more
> performant interface, but I also don't think their value is absolute
> zero either.
> 
> > That leaves us with 1). Now this is purely a platform specific matters,
> > not a spec matter. Once the HW has a way to enforce you can only
> > generate "allowed" MSIs it becomes a matter of having some FW mechanism
> > that can be used to 

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

[Benjamin Herrenschmidt]

On Wed, 2017-08-16 at 10:56 -0600, Alex Williamson wrote:
> 
> > WTF  Alex, can you stop once and for all with all that "POWER is
> > not standard" bullshit please ? It's completely wrong.
> 
> As you've stated, the MSI-X vector table on POWER is currently updated
> via a hypercall.  POWER is overall PCI compliant (I assume), but the
> guest does not directly modify the vector table in MMIO space of the
> device.  This is important...

Well no. On qemu the guest doesn't always (but it can save/restore it),
but on PowerVM this is done by the FW running inside the partition
itself. And that firmware just does normal stores to the device table.

IE. The problem here isn't so much who does the actual stores to the
device table but where they get the address and data values from, which
isn't covered by the spec.

The added fact that qemu hijacks the stores not just to "remap" them
but also do the whole reuqesting of the interrupt etc... in the host
system is a qemu design choice which also hasn't any relation to the
spec (and arguably isnt' a great choice for our systems).

For example, on PowerVM, the HV assigns a pile of MSIs to the guest to
assign to its devices. The FW inside the guest does a default
assignment but that can be changed.

Thus the interrupts are effectively "hooked up" at the HV level at the
point where the PCI bridge is mapped into the guest.

> > This has nothing to do with PCIe standard !
> 
> Yes, it actually does, because if the guest relies on the vector table
> to be virtualized then it doesn't particularly matter whether the
> vfio-pci kernel driver allows that portion of device MMIO space to be
> directly accessed or mapped because QEMU needs for it to be trapped in
> order to provide that virtualization.

And this has nothing to do with the PCIe standard... this has
everything to do with a combination of qemu design choices and
defficient FW interfaces on x86 platforms.

> I'm not knocking POWER, it's a smart thing for virtualization to have
> defined this hypercall which negates the need for vector table
> virtualization and allows efficient mapping of the device.  On other
> platform, it's not necessarily practical given the broad base of legacy
> guests supported where we'd never get agreement to implement this as
> part of the platform spec... if there even was such a thing.  Maybe we
> could provide the hypercall and dynamically enable direct vector table
> mapping (disabling vector table virtualization) only if the hypercall
> is used.

No I think a better approach would be to provide the guest with a pile
of MSIs to use with devices and have FW (such as ACPI) tell the guest
about them.

> > The PCIe standard says strictly *nothing* whatsoever about how an OS
> > obtains the magic address/values to put in the device and how the PCIe
> > host bridge may do appropriate fitering.
> 
> And now we've jumped the tracks...  The only way the platform specific
> address/data values become important is if we allow direct access to
> the vector table AND now we're formulating how the user/guest might
> write to it directly.  Otherwise the virtualization of the vector
> table, or paravirtualization via hypercall provides the translation
> where the host and guest address/data pairs can operate in completely
> different address spaces.

They can regardless if things are done properly :-)

> > There is nothing on POWER that prevents the guest from writing the MSI-
> > X address/data by hand. The problem isn't who writes the values or even
> > how. The problem breaks down into these two things that are NOT covered
> > by any aspect of the PCIe standard:
> 
> You've moved on to a different problem, I think everyone aside from
> POWER is still back at the problem where who writes the vector table
> values is a forefront problem.
>  
> >   1- The OS needs to obtain address/data values for an MSI that will
> > "work" for the device.
> > 
> >   2- The HW+HV needs to prevent collateral damage caused by a device
> > issuing stores to incorrect address or with incorrect data. Now *this*
> > is necessary for *ANY* kind of DMA whether it's an MSI or something
> > else anyway.
> > 
> > Now, the filtering done by qemu is NOT a reasonable way to handle 2)
> > and whatever excluse about "making it harder" doesn't fly a meter when
> > it comes to security. Making it "harder to break accidentally" I also
> > don't buy, people don't just randomly put things in their MSI-X tables
> > "accidentally", that stuff works or doesn't.
> 
> As I said before, I'm not willing to preserve the weak attributes that
> blocking direct vector table access provides over pursuing a more
> performant interface, but I also don't think their value is absolute
> zero either.
> 
> > That leaves us with 1). Now this is purely a platform specific matters,
> > not a spec matter. Once the HW has a way to enforce you can only
> > generate "allowed" MSIs it becomes a matter of having some FW mechanism
> > that can be used to 

[PATCH] mcb: Fix an error handling path in 'chameleon_parse_cells()'

[Christophe JAILLET]

If 'chameleon_get_bar()' fails, we will return 0, which mean success.
We should return the corresponding error code instead.

Remove the useless initialisation of 'ret' which was hiding the issue.
(if 'ret' is not set, gcc generates a warning ("warning: ‘ret’ may be used
uninitialized in this function"))

Signed-off-by: Christophe JAILLET 
---
 drivers/mcb/mcb-parse.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mcb/mcb-parse.c b/drivers/mcb/mcb-parse.c
index ee7fb6ec96bd..7369bda3442f 100644
--- a/drivers/mcb/mcb-parse.c
+++ b/drivers/mcb/mcb-parse.c
@@ -182,7 +182,7 @@ int chameleon_parse_cells(struct mcb_bus *bus, phys_addr_t 
mapbase,
int num_cells = 0;
uint32_t dtype;
int bar_count;
-   int ret = 0;
+   int ret;
u32 hsize;
 
hsize = sizeof(struct chameleon_fpga_header);
@@ -210,8 +210,10 @@ int chameleon_parse_cells(struct mcb_bus *bus, phys_addr_t 
mapbase,
 header->filename);
 
bar_count = chameleon_get_bar(, mapbase, );
-   if (bar_count < 0)
+   if (bar_count < 0) {
+   ret = bar_count;
goto free_header;
+   }
 
for_each_chameleon_cell(dtype, p) {
switch (dtype) {
-- 
2.11.0

[PATCH] mcb: Fix an error handling path in 'chameleon_parse_cells()'

[Christophe JAILLET]

If 'chameleon_get_bar()' fails, we will return 0, which mean success.
We should return the corresponding error code instead.

Remove the useless initialisation of 'ret' which was hiding the issue.
(if 'ret' is not set, gcc generates a warning ("warning: ‘ret’ may be used
uninitialized in this function"))

Signed-off-by: Christophe JAILLET 
---
 drivers/mcb/mcb-parse.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mcb/mcb-parse.c b/drivers/mcb/mcb-parse.c
index ee7fb6ec96bd..7369bda3442f 100644
--- a/drivers/mcb/mcb-parse.c
+++ b/drivers/mcb/mcb-parse.c
@@ -182,7 +182,7 @@ int chameleon_parse_cells(struct mcb_bus *bus, phys_addr_t 
mapbase,
int num_cells = 0;
uint32_t dtype;
int bar_count;
-   int ret = 0;
+   int ret;
u32 hsize;
 
hsize = sizeof(struct chameleon_fpga_header);
@@ -210,8 +210,10 @@ int chameleon_parse_cells(struct mcb_bus *bus, phys_addr_t 
mapbase,
 header->filename);
 
bar_count = chameleon_get_bar(, mapbase, );
-   if (bar_count < 0)
+   if (bar_count < 0) {
+   ret = bar_count;
goto free_header;
+   }
 
for_each_chameleon_cell(dtype, p) {
switch (dtype) {
-- 
2.11.0

Re: [PATCH net RESEND] PCI: fix oops when try to find Root Port for a PCI device

[Michael Ellerman]

Thierry Reding  writes:
...
>
> In case of Tegra, dev actually points to the root port. Now if I read
> the above code correctly, highest_pcie_bridge will still be NULL in that
> case, which in turn will return NULL from pci_find_pcie_root_port(). But
> shouldn't it really return dev?
>
> The patch that I used to fix the issue is this:
>
> --->8---
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 2c712dcfd37d..dd56c1c05614 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -514,7 +514,7 @@ EXPORT_SYMBOL(pci_find_resource);
>   */
>  struct pci_dev *pci_find_pcie_root_port(struct pci_dev *dev)
>  {
> -   struct pci_dev *bridge, *highest_pcie_bridge = NULL;
> +   struct pci_dev *bridge, *highest_pcie_bridge = dev;
>  
> bridge = pci_upstream_bridge(dev);
> while (bridge && pci_is_pcie(bridge)) {
> --->8---
>
> That works correctly if this function ends up being called on the PCIe
> root port, though perhaps that's not what this function is supposed to
> do. It's somewhat unclear from the kerneldoc what the function should
> be doing when called on a root port device itself.

That also works for me on powerpc (oops reported up thread).

cheers

Re: [PATCH net RESEND] PCI: fix oops when try to find Root Port for a PCI device

[Michael Ellerman]

Thierry Reding  writes:
...
>
> In case of Tegra, dev actually points to the root port. Now if I read
> the above code correctly, highest_pcie_bridge will still be NULL in that
> case, which in turn will return NULL from pci_find_pcie_root_port(). But
> shouldn't it really return dev?
>
> The patch that I used to fix the issue is this:
>
> --->8---
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 2c712dcfd37d..dd56c1c05614 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -514,7 +514,7 @@ EXPORT_SYMBOL(pci_find_resource);
>   */
>  struct pci_dev *pci_find_pcie_root_port(struct pci_dev *dev)
>  {
> -   struct pci_dev *bridge, *highest_pcie_bridge = NULL;
> +   struct pci_dev *bridge, *highest_pcie_bridge = dev;
>  
> bridge = pci_upstream_bridge(dev);
> while (bridge && pci_is_pcie(bridge)) {
> --->8---
>
> That works correctly if this function ends up being called on the PCIe
> root port, though perhaps that's not what this function is supposed to
> do. It's somewhat unclear from the kerneldoc what the function should
> be doing when called on a root port device itself.

That also works for me on powerpc (oops reported up thread).

cheers

Re: [PATCH] ARM: sun8i: a83t: Add device tree for Sinovoip Bananapi BPI-M3

[icenowy]

在 2017-08-17 11:40，Chen-Yu Tsai 写道：

The BPI-M3 is an Allwinner A83T based SBC in the Bananapi/Bpi family.
It is roughly the same form factor as the BPI-M1+, with roughly the
same peripherals and connectors:

  - 2GB LPDDR3 DRAM
  - 8GB eMMC
  - Micro-SD card slot
  - HDMI output
  - Headset (stereo + mic) jack
  - Onboard mic
  - Gigabit Ethernet with RTL8211E transceiver
  - Ampak AP6212 WiFi + BT
  - USB OTG connector
  - USB-to-SATA bridge connected through a USB 2.0 hub
  - Consumer IR receiver
  - MIPI DSI LCD panel connector
  - Camera interface (parallel and MIPI CSI) connector
  - 3 LEDs (Red, Green, Blue), of which 2 are controllable (GB)
  - Raspberry Pi 2 compatible GPIO header

Signed-off-by: Chen-Yu Tsai 
---

Note that the file name follows the convention of most of the other
bananapi boards, that is the vendor "sinovoip" is not included in
the name. This deviates from what is already in U-boot.

This applies on top of my A83t USB patches.

---
 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 148 
+++

 2 files changed, 149 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e0d77ab79f5f..791fecc0774a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -903,6 +903,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
+   sun8i-a83t-bananapi-m3.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
new file mode 100644
index ..2bafd7e99ef7
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -0,0 +1,148 @@
+/*
+ * Copyright 2017 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of 
the

+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a83t.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+
+/ {
+   model = "Banana Pi BPI-M3";
+   compatible = "sinovoip,bpi-m3", "allwinner,sun8i-a83t";


Should we continue to use sinovoip,bpi-mx-xxx or use bananapi,mx-xxx
instead?


+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   /* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
+   status = "okay";
+
+   /* TODO GL830 USB-to-SATA bridge downstream w/ GPIO power controls */
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+   cd-inverted;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_8bit_emmc_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <8>;
+ 

Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

[Lan Tianyu]

On 2017年08月16日 17:25, Paolo Bonzini wrote:
> On 16/08/2017 03:58, Lan Tianyu wrote:
>> These CR3 VMEXITs was introduced for platform without "unrestricted guest"
>> support. This is to set ept identity table to guest CR3 in guest real
>> mode because these platforms don't support ept real mode(CR0.PE and CR0.PG
>> must be set to 1). But these VMEXITs is redundant for platforms with
>> "unrestricted guest" support.
> 
> This is true, but I'm not sure it's a good idea to make things more
> complex...  It is working code and is not a bottleneck anywhere.

Yes, this is just code clear up and will not affect function.
I thought this change was missed when introduced unrestricted guest support.

-- 
Best regards
Tianyu Lan
> 
> Paolo
> 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/vmx.c | 22 +-
>>  1 file changed, 13 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 9b21b12..46dcf50 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -4221,18 +4221,20 @@ static void ept_update_paging_mode_cr0(unsigned long 
>> *hw_cr0,
>>  vmx_decache_cr3(vcpu);
>>  if (!(cr0 & X86_CR0_PG)) {
>>  /* From paging/starting to nonpaging */
>> -vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> - vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) |
>> - (CPU_BASED_CR3_LOAD_EXITING |
>> -  CPU_BASED_CR3_STORE_EXITING));
>> +if (!enable_unrestricted_guest)
>> +vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> + vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) |
>> + (CPU_BASED_CR3_LOAD_EXITING |
>> +  CPU_BASED_CR3_STORE_EXITING));
>>  vcpu->arch.cr0 = cr0;
>>  vmx_set_cr4(vcpu, kvm_read_cr4(vcpu));
>>  } else if (!is_paging(vcpu)) {
>>  /* From nonpaging to paging */
>> -vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> - vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
>> - ~(CPU_BASED_CR3_LOAD_EXITING |
>> -   CPU_BASED_CR3_STORE_EXITING));
>> +if (!enable_unrestricted_guest)
>> +vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> + vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
>> + ~(CPU_BASED_CR3_LOAD_EXITING |
>> +   CPU_BASED_CR3_STORE_EXITING));
>>  vcpu->arch.cr0 = cr0;
>>  vmx_set_cr4(vcpu, kvm_read_cr4(vcpu));
>>  }
>> @@ -4311,7 +4313,9 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, 
>> unsigned long cr3)
>>  }
>>  
>>  vmx_flush_tlb(vcpu);
>> -vmcs_writel(GUEST_CR3, guest_cr3);
>> +
>> +if (!enable_unrestricted_guest || !enable_ept)
>> +vmcs_writel(GUEST_CR3, guest_cr3);
>>  }
>>  
>>  static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
>>
> 

Re: [PATCH] ARM: sun8i: a83t: Add device tree for Sinovoip Bananapi BPI-M3

[icenowy]

在 2017-08-17 11:40，Chen-Yu Tsai 写道：

The BPI-M3 is an Allwinner A83T based SBC in the Bananapi/Bpi family.
It is roughly the same form factor as the BPI-M1+, with roughly the
same peripherals and connectors:

  - 2GB LPDDR3 DRAM
  - 8GB eMMC
  - Micro-SD card slot
  - HDMI output
  - Headset (stereo + mic) jack
  - Onboard mic
  - Gigabit Ethernet with RTL8211E transceiver
  - Ampak AP6212 WiFi + BT
  - USB OTG connector
  - USB-to-SATA bridge connected through a USB 2.0 hub
  - Consumer IR receiver
  - MIPI DSI LCD panel connector
  - Camera interface (parallel and MIPI CSI) connector
  - 3 LEDs (Red, Green, Blue), of which 2 are controllable (GB)
  - Raspberry Pi 2 compatible GPIO header

Signed-off-by: Chen-Yu Tsai 
---

Note that the file name follows the convention of most of the other
bananapi boards, that is the vendor "sinovoip" is not included in
the name. This deviates from what is already in U-boot.

This applies on top of my A83t USB patches.

---
 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 148 
+++

 2 files changed, 149 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e0d77ab79f5f..791fecc0774a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -903,6 +903,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
+   sun8i-a83t-bananapi-m3.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
new file mode 100644
index ..2bafd7e99ef7
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -0,0 +1,148 @@
+/*
+ * Copyright 2017 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of 
the

+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a83t.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+
+/ {
+   model = "Banana Pi BPI-M3";
+   compatible = "sinovoip,bpi-m3", "allwinner,sun8i-a83t";


Should we continue to use sinovoip,bpi-mx-xxx or use bananapi,mx-xxx
instead?


+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   /* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
+   status = "okay";
+
+   /* TODO GL830 USB-to-SATA bridge downstream w/ GPIO power controls */
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+   cd-inverted;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_8bit_emmc_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <8>;
+   non-removable;
+   

Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

[Lan Tianyu]

On 2017年08月16日 17:25, Paolo Bonzini wrote:
> On 16/08/2017 03:58, Lan Tianyu wrote:
>> These CR3 VMEXITs was introduced for platform without "unrestricted guest"
>> support. This is to set ept identity table to guest CR3 in guest real
>> mode because these platforms don't support ept real mode(CR0.PE and CR0.PG
>> must be set to 1). But these VMEXITs is redundant for platforms with
>> "unrestricted guest" support.
> 
> This is true, but I'm not sure it's a good idea to make things more
> complex...  It is working code and is not a bottleneck anywhere.

Yes, this is just code clear up and will not affect function.
I thought this change was missed when introduced unrestricted guest support.

-- 
Best regards
Tianyu Lan
> 
> Paolo
> 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/vmx.c | 22 +-
>>  1 file changed, 13 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 9b21b12..46dcf50 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -4221,18 +4221,20 @@ static void ept_update_paging_mode_cr0(unsigned long 
>> *hw_cr0,
>>  vmx_decache_cr3(vcpu);
>>  if (!(cr0 & X86_CR0_PG)) {
>>  /* From paging/starting to nonpaging */
>> -vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> - vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) |
>> - (CPU_BASED_CR3_LOAD_EXITING |
>> -  CPU_BASED_CR3_STORE_EXITING));
>> +if (!enable_unrestricted_guest)
>> +vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> + vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) |
>> + (CPU_BASED_CR3_LOAD_EXITING |
>> +  CPU_BASED_CR3_STORE_EXITING));
>>  vcpu->arch.cr0 = cr0;
>>  vmx_set_cr4(vcpu, kvm_read_cr4(vcpu));
>>  } else if (!is_paging(vcpu)) {
>>  /* From nonpaging to paging */
>> -vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> - vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
>> - ~(CPU_BASED_CR3_LOAD_EXITING |
>> -   CPU_BASED_CR3_STORE_EXITING));
>> +if (!enable_unrestricted_guest)
>> +vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
>> + vmcs_read32(CPU_BASED_VM_EXEC_CONTROL) &
>> + ~(CPU_BASED_CR3_LOAD_EXITING |
>> +   CPU_BASED_CR3_STORE_EXITING));
>>  vcpu->arch.cr0 = cr0;
>>  vmx_set_cr4(vcpu, kvm_read_cr4(vcpu));
>>  }
>> @@ -4311,7 +4313,9 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, 
>> unsigned long cr3)
>>  }
>>  
>>  vmx_flush_tlb(vcpu);
>> -vmcs_writel(GUEST_CR3, guest_cr3);
>> +
>> +if (!enable_unrestricted_guest || !enable_ept)
>> +vmcs_writel(GUEST_CR3, guest_cr3);
>>  }
>>  
>>  static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
>>
> 

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

[Daniel Micay]

On Wed, 2017-08-16 at 21:58 -0700, Kees Cook wrote:
> On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich 
> wrote:
> > On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott 
> > wrote:
> > > From: Daniel Micay 
> > > 
> > > Existing Android bootloaders usually pass data useful as early
> > > entropy
> > > on the kernel command-line. It may also be the case on other
> > > embedded
> > > systems. Sample command-line from a Google Pixel running
> > > CopperheadOS:
> > > 
> > 
> > Why is it better to put this into the kernel, rather than just rely
> > on
> > the existing userspace functionality which does exactly the same
> > thing? This is what Android already does today:
> > https://android-review.googlesource.com/198113
> 
> That's too late for setting up the kernel stack canary, among other
> things. The kernel will also be generating some early secrets for slab
> cache canaries, etc. That all needs to happen well before init is
> started.
> 
> -Kees
> 

It's also unfortunately the kernel's global stack canary for the entire
boot since unlike x86 there aren't per-task canaries. GCC / Clang access
it via a segment register on x86 vs. a global on other architectures.

In theory it could be task-local elsewhere but doing it efficiently
would imply reserving a register to store the random value. I think that
may actually end up helping performance more than it hurts by not
needing to read the global stack canary value from cache repeatedly. If
stack canaries were augmented into something more (XOR in the retaddr
and offer the option of more coverage than STRONG) it would be more
important.

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

[Daniel Micay]

On Wed, 2017-08-16 at 21:58 -0700, Kees Cook wrote:
> On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich 
> wrote:
> > On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott 
> > wrote:
> > > From: Daniel Micay 
> > > 
> > > Existing Android bootloaders usually pass data useful as early
> > > entropy
> > > on the kernel command-line. It may also be the case on other
> > > embedded
> > > systems. Sample command-line from a Google Pixel running
> > > CopperheadOS:
> > > 
> > 
> > Why is it better to put this into the kernel, rather than just rely
> > on
> > the existing userspace functionality which does exactly the same
> > thing? This is what Android already does today:
> > https://android-review.googlesource.com/198113
> 
> That's too late for setting up the kernel stack canary, among other
> things. The kernel will also be generating some early secrets for slab
> cache canaries, etc. That all needs to happen well before init is
> started.
> 
> -Kees
> 

It's also unfortunately the kernel's global stack canary for the entire
boot since unlike x86 there aren't per-task canaries. GCC / Clang access
it via a segment register on x86 vs. a global on other architectures.

In theory it could be task-local elsewhere but doing it efficiently
would imply reserving a register to store the random value. I think that
may actually end up helping performance more than it hurts by not
needing to read the global stack canary value from cache repeatedly. If
stack canaries were augmented into something more (XOR in the retaddr
and offer the option of more coverage than STRONG) it would be more
important.

Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

[Lan Tianyu]

On 2017年08月16日 21:26, Radim Krčmář wrote:
> 2017-08-15 21:58-0400, Lan Tianyu:
>> These CR3 VMEXITs was introduced for platform without "unrestricted guest"
>> support. This is to set ept identity table to guest CR3 in guest real
>> mode because these platforms don't support ept real mode(CR0.PE and CR0.PG
>> must be set to 1). But these VMEXITs is redundant for platforms with
>> "unrestricted guest" support.
>>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/vmx.c | 22 +-
>>  1 file changed, 13 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> @@ -4311,7 +4313,9 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, 
>> unsigned long cr3)
>>  }
>>  
>>  vmx_flush_tlb(vcpu);
>> -vmcs_writel(GUEST_CR3, guest_cr3);
>> +
>> +if (!enable_unrestricted_guest || !enable_ept)
>> +vmcs_writel(GUEST_CR3, guest_cr3);
> 
> This looks wrong -- it would prevent update GUEST_CR3 outside of
> non-root mode with enable_unrestricted_guest.
> 

OK. Do you mean nest mode? I didn't consider that case.
I thought there were three cases here.

1) Shadow page mode(enable_ept=0)

2) ept mode without unrestricted guest mode
   (ept=1, enable_unrestricted_guest = 0)

3) ept mode with unrestricted guest mode
   (ept=1, enable_unrestricted_guest = 1)

>From my understanding, only (1) and (2) need to update guest cr3.
If nest mode is still needed to update guest CR3, we can add
is_guest_mode() in the if condition. Other choice is to just ignore
setting guest cr3 for case3. The condition maybe changed to

if (!(enable_unrestricted_guest && enable_ept))
vmcs_writel(GUEST_CR3, guest_cr3);





-- 
Best regards
Tianyu Lan

Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

[Lan Tianyu]

On 2017年08月16日 21:26, Radim Krčmář wrote:
> 2017-08-15 21:58-0400, Lan Tianyu:
>> These CR3 VMEXITs was introduced for platform without "unrestricted guest"
>> support. This is to set ept identity table to guest CR3 in guest real
>> mode because these platforms don't support ept real mode(CR0.PE and CR0.PG
>> must be set to 1). But these VMEXITs is redundant for platforms with
>> "unrestricted guest" support.
>>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  arch/x86/kvm/vmx.c | 22 +-
>>  1 file changed, 13 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> @@ -4311,7 +4313,9 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, 
>> unsigned long cr3)
>>  }
>>  
>>  vmx_flush_tlb(vcpu);
>> -vmcs_writel(GUEST_CR3, guest_cr3);
>> +
>> +if (!enable_unrestricted_guest || !enable_ept)
>> +vmcs_writel(GUEST_CR3, guest_cr3);
> 
> This looks wrong -- it would prevent update GUEST_CR3 outside of
> non-root mode with enable_unrestricted_guest.
> 

OK. Do you mean nest mode? I didn't consider that case.
I thought there were three cases here.

1) Shadow page mode(enable_ept=0)

2) ept mode without unrestricted guest mode
   (ept=1, enable_unrestricted_guest = 0)

3) ept mode with unrestricted guest mode
   (ept=1, enable_unrestricted_guest = 1)

>From my understanding, only (1) and (2) need to update guest cr3.
If nest mode is still needed to update guest CR3, we can add
is_guest_mode() in the if condition. Other choice is to just ignore
setting guest cr3 for case3. The condition maybe changed to

if (!(enable_unrestricted_guest && enable_ept))
vmcs_writel(GUEST_CR3, guest_cr3);





-- 
Best regards
Tianyu Lan

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

[Kees Cook]

On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich  wrote:
> On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott  wrote:
>> From: Daniel Micay 
>>
>> Existing Android bootloaders usually pass data useful as early entropy
>> on the kernel command-line. It may also be the case on other embedded
>> systems. Sample command-line from a Google Pixel running CopperheadOS:
>>
>
> Why is it better to put this into the kernel, rather than just rely on
> the existing userspace functionality which does exactly the same
> thing? This is what Android already does today:
> https://android-review.googlesource.com/198113

That's too late for setting up the kernel stack canary, among other
things. The kernel will also be generating some early secrets for slab
cache canaries, etc. That all needs to happen well before init is
started.

-Kees

-- 
Kees Cook
Pixel Security

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

[Kees Cook]

On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich  wrote:
> On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott  wrote:
>> From: Daniel Micay 
>>
>> Existing Android bootloaders usually pass data useful as early entropy
>> on the kernel command-line. It may also be the case on other embedded
>> systems. Sample command-line from a Google Pixel running CopperheadOS:
>>
>
> Why is it better to put this into the kernel, rather than just rely on
> the existing userspace functionality which does exactly the same
> thing? This is what Android already does today:
> https://android-review.googlesource.com/198113

That's too late for setting up the kernel stack canary, among other
things. The kernel will also be generating some early secrets for slab
cache canaries, etc. That all needs to happen well before init is
started.

-Kees

-- 
Kees Cook
Pixel Security

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

[Nick Kralevich]

On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott  wrote:
> From: Daniel Micay 
>
> Existing Android bootloaders usually pass data useful as early entropy
> on the kernel command-line. It may also be the case on other embedded
> systems. Sample command-line from a Google Pixel running CopperheadOS:
>

Why is it better to put this into the kernel, rather than just rely on
the existing userspace functionality which does exactly the same
thing? This is what Android already does today:
https://android-review.googlesource.com/198113

-- Nick

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

[Nick Kralevich]

On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott  wrote:
> From: Daniel Micay 
>
> Existing Android bootloaders usually pass data useful as early entropy
> on the kernel command-line. It may also be the case on other embedded
> systems. Sample command-line from a Google Pixel running CopperheadOS:
>

Why is it better to put this into the kernel, rather than just rely on
the existing userspace functionality which does exactly the same
thing? This is what Android already does today:
https://android-review.googlesource.com/198113

-- Nick

[PATCH v3 6/9] ASoC: rockchip: Parse dai links from dts

[Jeffy Chen]

Refactor rockchip_sound_probe, parse dai links from dts instead of
hard coding them.

Signed-off-by: Jeffy Chen 
---

Changes in v3:
Use compatible to match audio codecs
-- Suggested-by Matthias Kaehlcke 

Changes in v2:
Let rockchip,codec-names be a required property, because we plan to
add more supported codecs to the fixed dai link list in the driver.

 sound/soc/rockchip/rk3399_gru_sound.c | 139 ++
 1 file changed, 91 insertions(+), 48 deletions(-)

diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 9b7e28703bfb..d532336871d7 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -235,14 +235,42 @@ static const struct snd_soc_ops rockchip_sound_da7219_ops 
= {
.hw_params = rockchip_sound_da7219_hw_params,
 };
 
+static struct snd_soc_card rockchip_sound_card = {
+   .name = "rk3399-gru-sound",
+   .owner = THIS_MODULE,
+   .dapm_widgets = rockchip_dapm_widgets,
+   .num_dapm_widgets = ARRAY_SIZE(rockchip_dapm_widgets),
+   .dapm_routes = rockchip_dapm_routes,
+   .num_dapm_routes = ARRAY_SIZE(rockchip_dapm_routes),
+   .controls = rockchip_controls,
+   .num_controls = ARRAY_SIZE(rockchip_controls),
+};
+
 enum {
+   DAILINK_DA7219,
DAILINK_MAX98357A,
DAILINK_RT5514,
-   DAILINK_DA7219,
DAILINK_RT5514_DSP,
 };
 
-static struct snd_soc_dai_link rockchip_dailinks[] = {
+static const char * const dailink_compat[] = {
+   [DAILINK_DA7219] = "dlg,da7219",
+   [DAILINK_MAX98357A] = "maxim,max98357a",
+   [DAILINK_RT5514] = "realtek,rt5514-i2c",
+   [DAILINK_RT5514_DSP] = "realtek,rt5514-spi",
+};
+
+static const struct snd_soc_dai_link rockchip_dais[] = {
+   [DAILINK_DA7219] = {
+   .name = "DA7219",
+   .stream_name = "DA7219 PCM",
+   .codec_dai_name = "da7219-hifi",
+   .init = rockchip_sound_da7219_init,
+   .ops = _sound_da7219_ops,
+   /* set da7219 as slave */
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
[DAILINK_MAX98357A] = {
.name = "MAX98357A",
.stream_name = "MAX98357A PCM",
@@ -261,16 +289,6 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
},
-   [DAILINK_DA7219] = {
-   .name = "DA7219",
-   .stream_name = "DA7219 PCM",
-   .codec_dai_name = "da7219-hifi",
-   .init = rockchip_sound_da7219_init,
-   .ops = _sound_da7219_ops,
-   /* set da7219 as slave */
-   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
-   SND_SOC_DAIFMT_CBS_CFS,
-   },
/* RT5514 DSP for voice wakeup via spi bus */
[DAILINK_RT5514_DSP] = {
.name = "RT5514 DSP",
@@ -279,53 +297,78 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
},
 };
 
-static struct snd_soc_card rockchip_sound_card = {
-   .name = "rk3399-gru-sound",
-   .owner = THIS_MODULE,
-   .dai_link = rockchip_dailinks,
-   .num_links =  ARRAY_SIZE(rockchip_dailinks),
-   .dapm_widgets = rockchip_dapm_widgets,
-   .num_dapm_widgets = ARRAY_SIZE(rockchip_dapm_widgets),
-   .dapm_routes = rockchip_dapm_routes,
-   .num_dapm_routes = ARRAY_SIZE(rockchip_dapm_routes),
-   .controls = rockchip_controls,
-   .num_controls = ARRAY_SIZE(rockchip_controls),
-};
-
-static int rockchip_sound_probe(struct platform_device *pdev)
+static int rockchip_sound_codec_node_match(struct device_node *np_codec)
 {
-   struct snd_soc_card *card = _sound_card;
-   struct device_node *cpu_node;
-   int i, ret;
+   int i;
 
-   cpu_node = of_parse_phandle(pdev->dev.of_node, "rockchip,cpu", 0);
-   if (!cpu_node) {
-   dev_err(>dev, "Property 'rockchip,cpu' missing or 
invalid\n");
-   return -EINVAL;
+   for (i = 0; i < ARRAY_SIZE(dailink_compat); i++) {
+   if (of_device_is_compatible(np_codec, dailink_compat[i]))
+   return i;
}
+   return -1;
+}
 
-   for (i = 0; i < ARRAY_SIZE(rockchip_dailinks); i++) {
-   rockchip_dailinks[i].platform_of_node = cpu_node;
-   rockchip_dailinks[i].cpu_of_node = cpu_node;
-
-   rockchip_dailinks[i].codec_of_node =
-   of_parse_phandle(pdev->dev.of_node, "rockchip,codec", 
i);
-   if (!rockchip_dailinks[i].codec_of_node) {
-   dev_err(>dev,
-   "Property[%d] 'rockchip,codec' missing or 
invalid\n", i);
+static int rockchip_sound_of_parse_dais(struct 

[PATCH v3 6/9] ASoC: rockchip: Parse dai links from dts

[Jeffy Chen]

Refactor rockchip_sound_probe, parse dai links from dts instead of
hard coding them.

Signed-off-by: Jeffy Chen 
---

Changes in v3:
Use compatible to match audio codecs
-- Suggested-by Matthias Kaehlcke 

Changes in v2:
Let rockchip,codec-names be a required property, because we plan to
add more supported codecs to the fixed dai link list in the driver.

 sound/soc/rockchip/rk3399_gru_sound.c | 139 ++
 1 file changed, 91 insertions(+), 48 deletions(-)

diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 9b7e28703bfb..d532336871d7 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -235,14 +235,42 @@ static const struct snd_soc_ops rockchip_sound_da7219_ops 
= {
.hw_params = rockchip_sound_da7219_hw_params,
 };
 
+static struct snd_soc_card rockchip_sound_card = {
+   .name = "rk3399-gru-sound",
+   .owner = THIS_MODULE,
+   .dapm_widgets = rockchip_dapm_widgets,
+   .num_dapm_widgets = ARRAY_SIZE(rockchip_dapm_widgets),
+   .dapm_routes = rockchip_dapm_routes,
+   .num_dapm_routes = ARRAY_SIZE(rockchip_dapm_routes),
+   .controls = rockchip_controls,
+   .num_controls = ARRAY_SIZE(rockchip_controls),
+};
+
 enum {
+   DAILINK_DA7219,
DAILINK_MAX98357A,
DAILINK_RT5514,
-   DAILINK_DA7219,
DAILINK_RT5514_DSP,
 };
 
-static struct snd_soc_dai_link rockchip_dailinks[] = {
+static const char * const dailink_compat[] = {
+   [DAILINK_DA7219] = "dlg,da7219",
+   [DAILINK_MAX98357A] = "maxim,max98357a",
+   [DAILINK_RT5514] = "realtek,rt5514-i2c",
+   [DAILINK_RT5514_DSP] = "realtek,rt5514-spi",
+};
+
+static const struct snd_soc_dai_link rockchip_dais[] = {
+   [DAILINK_DA7219] = {
+   .name = "DA7219",
+   .stream_name = "DA7219 PCM",
+   .codec_dai_name = "da7219-hifi",
+   .init = rockchip_sound_da7219_init,
+   .ops = _sound_da7219_ops,
+   /* set da7219 as slave */
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
[DAILINK_MAX98357A] = {
.name = "MAX98357A",
.stream_name = "MAX98357A PCM",
@@ -261,16 +289,6 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
},
-   [DAILINK_DA7219] = {
-   .name = "DA7219",
-   .stream_name = "DA7219 PCM",
-   .codec_dai_name = "da7219-hifi",
-   .init = rockchip_sound_da7219_init,
-   .ops = _sound_da7219_ops,
-   /* set da7219 as slave */
-   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
-   SND_SOC_DAIFMT_CBS_CFS,
-   },
/* RT5514 DSP for voice wakeup via spi bus */
[DAILINK_RT5514_DSP] = {
.name = "RT5514 DSP",
@@ -279,53 +297,78 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
},
 };
 
-static struct snd_soc_card rockchip_sound_card = {
-   .name = "rk3399-gru-sound",
-   .owner = THIS_MODULE,
-   .dai_link = rockchip_dailinks,
-   .num_links =  ARRAY_SIZE(rockchip_dailinks),
-   .dapm_widgets = rockchip_dapm_widgets,
-   .num_dapm_widgets = ARRAY_SIZE(rockchip_dapm_widgets),
-   .dapm_routes = rockchip_dapm_routes,
-   .num_dapm_routes = ARRAY_SIZE(rockchip_dapm_routes),
-   .controls = rockchip_controls,
-   .num_controls = ARRAY_SIZE(rockchip_controls),
-};
-
-static int rockchip_sound_probe(struct platform_device *pdev)
+static int rockchip_sound_codec_node_match(struct device_node *np_codec)
 {
-   struct snd_soc_card *card = _sound_card;
-   struct device_node *cpu_node;
-   int i, ret;
+   int i;
 
-   cpu_node = of_parse_phandle(pdev->dev.of_node, "rockchip,cpu", 0);
-   if (!cpu_node) {
-   dev_err(>dev, "Property 'rockchip,cpu' missing or 
invalid\n");
-   return -EINVAL;
+   for (i = 0; i < ARRAY_SIZE(dailink_compat); i++) {
+   if (of_device_is_compatible(np_codec, dailink_compat[i]))
+   return i;
}
+   return -1;
+}
 
-   for (i = 0; i < ARRAY_SIZE(rockchip_dailinks); i++) {
-   rockchip_dailinks[i].platform_of_node = cpu_node;
-   rockchip_dailinks[i].cpu_of_node = cpu_node;
-
-   rockchip_dailinks[i].codec_of_node =
-   of_parse_phandle(pdev->dev.of_node, "rockchip,codec", 
i);
-   if (!rockchip_dailinks[i].codec_of_node) {
-   dev_err(>dev,
-   "Property[%d] 'rockchip,codec' missing or 
invalid\n", i);
+static int rockchip_sound_of_parse_dais(struct device *dev,
+ 

[PATCH v3 9/9] dt-bindings: ASoC: rockchip: Update description of rockchip,codec

[Jeffy Chen]

Update description for newly added optional audio codecs.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
index f19b6c830a34..f54b4e91e97c 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: "rockchip,rk3399-gru-sound"
 - rockchip,cpu: The phandle of the Rockchip I2S controller that's
   connected to the codecs
-- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
+- rockchip,codec: The phandle of the audio codecs
 
 Example:
 
-- 
2.11.0

[PATCH v3 9/9] dt-bindings: ASoC: rockchip: Update description of rockchip,codec

[Jeffy Chen]

Update description for newly added optional audio codecs.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
index f19b6c830a34..f54b4e91e97c 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: "rockchip,rk3399-gru-sound"
 - rockchip,cpu: The phandle of the Rockchip I2S controller that's
   connected to the codecs
-- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
+- rockchip,codec: The phandle of the audio codecs
 
 Example:
 
-- 
2.11.0

[PATCH v3 8/9] ASoC: rockchip: Add support for DMIC codec

[Jeffy Chen]

Add support for optional dmic codec.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 sound/soc/rockchip/Kconfig|  1 +
 sound/soc/rockchip/rk3399_gru_sound.c | 33 +
 2 files changed, 34 insertions(+)

diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index 8f0d0d8d34e6..b0825370d262 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -69,6 +69,7 @@ config SND_SOC_RK3399_GRU_SOUND
select SND_SOC_DA7219
select SND_SOC_RT5514_SPI
select SND_SOC_HDMI_CODEC
+   select SND_SOC_DMIC
help
  Say Y or M here if you want to add support multiple codecs for SoC
  audio on Rockchip RK3399 GRU boards.
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 8ffae1934b94..0be3e5c1386f 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -262,6 +262,25 @@ static int rockchip_sound_cdndp_hw_params(struct 
snd_pcm_substream *substream,
return 0;
 }
 
+static int rockchip_sound_dmic_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   unsigned int mclk;
+   int ret;
+
+   mclk = params_rate(params) * SOUND_FS;
+
+   ret = snd_soc_dai_set_sysclk(rtd->cpu_dai, 0, mclk, 0);
+   if (ret) {
+   dev_err(rtd->card->dev, "%s() error setting sysclk to %u: %d\n",
+   __func__, mclk, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct snd_soc_ops rockchip_sound_max98357a_ops = {
.hw_params = rockchip_sound_max98357a_hw_params,
 };
@@ -278,6 +297,10 @@ static struct snd_soc_ops rockchip_sound_cdndp_ops = {
.hw_params = rockchip_sound_cdndp_hw_params,
 };
 
+static struct snd_soc_ops rockchip_sound_dmic_ops = {
+   .hw_params = rockchip_sound_dmic_hw_params,
+};
+
 static struct snd_soc_card rockchip_sound_card = {
.name = "rk3399-gru-sound",
.owner = THIS_MODULE,
@@ -292,6 +315,7 @@ static struct snd_soc_card rockchip_sound_card = {
 enum {
DAILINK_CDNDP,
DAILINK_DA7219,
+   DAILINK_DMIC,
DAILINK_MAX98357A,
DAILINK_RT5514,
DAILINK_RT5514_DSP,
@@ -300,6 +324,7 @@ enum {
 static const char * const dailink_compat[] = {
[DAILINK_CDNDP] = "rockchip,rk3399-cdn-dp",
[DAILINK_DA7219] = "dlg,da7219",
+   [DAILINK_DMIC] = "dmic-codec",
[DAILINK_MAX98357A] = "maxim,max98357a",
[DAILINK_RT5514] = "realtek,rt5514-i2c",
[DAILINK_RT5514_DSP] = "realtek,rt5514-spi",
@@ -324,6 +349,14 @@ static const struct snd_soc_dai_link rockchip_dais[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
},
+   [DAILINK_DMIC] = {
+   .name = "DMIC",
+   .stream_name = "DMIC PCM",
+   .codec_dai_name = "dmic-hifi",
+   .ops = _sound_dmic_ops,
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
[DAILINK_MAX98357A] = {
.name = "MAX98357A",
.stream_name = "MAX98357A PCM",
-- 
2.11.0

[PATCH v3 8/9] ASoC: rockchip: Add support for DMIC codec

[Jeffy Chen]

Add support for optional dmic codec.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 sound/soc/rockchip/Kconfig|  1 +
 sound/soc/rockchip/rk3399_gru_sound.c | 33 +
 2 files changed, 34 insertions(+)

diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index 8f0d0d8d34e6..b0825370d262 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -69,6 +69,7 @@ config SND_SOC_RK3399_GRU_SOUND
select SND_SOC_DA7219
select SND_SOC_RT5514_SPI
select SND_SOC_HDMI_CODEC
+   select SND_SOC_DMIC
help
  Say Y or M here if you want to add support multiple codecs for SoC
  audio on Rockchip RK3399 GRU boards.
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 8ffae1934b94..0be3e5c1386f 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -262,6 +262,25 @@ static int rockchip_sound_cdndp_hw_params(struct 
snd_pcm_substream *substream,
return 0;
 }
 
+static int rockchip_sound_dmic_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   unsigned int mclk;
+   int ret;
+
+   mclk = params_rate(params) * SOUND_FS;
+
+   ret = snd_soc_dai_set_sysclk(rtd->cpu_dai, 0, mclk, 0);
+   if (ret) {
+   dev_err(rtd->card->dev, "%s() error setting sysclk to %u: %d\n",
+   __func__, mclk, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct snd_soc_ops rockchip_sound_max98357a_ops = {
.hw_params = rockchip_sound_max98357a_hw_params,
 };
@@ -278,6 +297,10 @@ static struct snd_soc_ops rockchip_sound_cdndp_ops = {
.hw_params = rockchip_sound_cdndp_hw_params,
 };
 
+static struct snd_soc_ops rockchip_sound_dmic_ops = {
+   .hw_params = rockchip_sound_dmic_hw_params,
+};
+
 static struct snd_soc_card rockchip_sound_card = {
.name = "rk3399-gru-sound",
.owner = THIS_MODULE,
@@ -292,6 +315,7 @@ static struct snd_soc_card rockchip_sound_card = {
 enum {
DAILINK_CDNDP,
DAILINK_DA7219,
+   DAILINK_DMIC,
DAILINK_MAX98357A,
DAILINK_RT5514,
DAILINK_RT5514_DSP,
@@ -300,6 +324,7 @@ enum {
 static const char * const dailink_compat[] = {
[DAILINK_CDNDP] = "rockchip,rk3399-cdn-dp",
[DAILINK_DA7219] = "dlg,da7219",
+   [DAILINK_DMIC] = "dmic-codec",
[DAILINK_MAX98357A] = "maxim,max98357a",
[DAILINK_RT5514] = "realtek,rt5514-i2c",
[DAILINK_RT5514_DSP] = "realtek,rt5514-spi",
@@ -324,6 +349,14 @@ static const struct snd_soc_dai_link rockchip_dais[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
},
+   [DAILINK_DMIC] = {
+   .name = "DMIC",
+   .stream_name = "DMIC PCM",
+   .codec_dai_name = "dmic-hifi",
+   .ops = _sound_dmic_ops,
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
[DAILINK_MAX98357A] = {
.name = "MAX98357A",
.stream_name = "MAX98357A PCM",
-- 
2.11.0

[PATCH v3 4/9] arm64: dts: rockchip: Add rt5514 dsp for Gru

[Jeffy Chen]

Add rt5514 dsp of_node to codec list for Gru boards.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index d48e98b62d09..2713129722a1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -514,7 +514,8 @@
sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = < >;
-   rockchip,codec = <  >;
+   rockchip,codec = < 
+  _spi_audio>;
};
 };
 
-- 
2.11.0

[PATCH v3 4/9] arm64: dts: rockchip: Add rt5514 dsp for Gru

[Jeffy Chen]

Add rt5514 dsp of_node to codec list for Gru boards.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index d48e98b62d09..2713129722a1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -514,7 +514,8 @@
sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = < >;
-   rockchip,codec = <  >;
+   rockchip,codec = < 
+  _spi_audio>;
};
 };
 
-- 
2.11.0

[PATCH v3 7/9] ASoC: rockchip: Add support for DP codec

[Jeffy Chen]

Add support for optional cdn dp codec.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 sound/soc/rockchip/Kconfig|  1 +
 sound/soc/rockchip/rk3399_gru_sound.c | 59 +--
 2 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index c84487805876..8f0d0d8d34e6 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -68,6 +68,7 @@ config SND_SOC_RK3399_GRU_SOUND
select SND_SOC_RT5514
select SND_SOC_DA7219
select SND_SOC_RT5514_SPI
+   select SND_SOC_HDMI_CODEC
help
  Say Y or M here if you want to add support multiple codecs for SoC
  audio on Rockchip RK3399 GRU boards.
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index d532336871d7..8ffae1934b94 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -223,6 +223,45 @@ static int rockchip_sound_da7219_init(struct 
snd_soc_pcm_runtime *rtd)
return 0;
 }
 
+static int rockchip_sound_cdndp_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+   struct snd_soc_dai *codec_dai = rtd->codec_dai;
+   int mclk, ret;
+
+   /* in bypass mode, the mclk has to be one of the frequencies below */
+   switch (params_rate(params)) {
+   case 8000:
+   case 16000:
+   case 24000:
+   case 32000:
+   case 48000:
+   case 64000:
+   case 96000:
+   mclk = 12288000;
+   break;
+   case 11025:
+   case 22050:
+   case 44100:
+   case 88200:
+   mclk = 11289600;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk,
+SND_SOC_CLOCK_OUT);
+   if (ret < 0) {
+   dev_err(codec_dai->dev, "Can't set cpu clock out %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct snd_soc_ops rockchip_sound_max98357a_ops = {
.hw_params = rockchip_sound_max98357a_hw_params,
 };
@@ -235,6 +274,10 @@ static const struct snd_soc_ops rockchip_sound_da7219_ops 
= {
.hw_params = rockchip_sound_da7219_hw_params,
 };
 
+static struct snd_soc_ops rockchip_sound_cdndp_ops = {
+   .hw_params = rockchip_sound_cdndp_hw_params,
+};
+
 static struct snd_soc_card rockchip_sound_card = {
.name = "rk3399-gru-sound",
.owner = THIS_MODULE,
@@ -247,6 +290,7 @@ static struct snd_soc_card rockchip_sound_card = {
 };
 
 enum {
+   DAILINK_CDNDP,
DAILINK_DA7219,
DAILINK_MAX98357A,
DAILINK_RT5514,
@@ -254,6 +298,7 @@ enum {
 };
 
 static const char * const dailink_compat[] = {
+   [DAILINK_CDNDP] = "rockchip,rk3399-cdn-dp",
[DAILINK_DA7219] = "dlg,da7219",
[DAILINK_MAX98357A] = "maxim,max98357a",
[DAILINK_RT5514] = "realtek,rt5514-i2c",
@@ -261,6 +306,14 @@ static const char * const dailink_compat[] = {
 };
 
 static const struct snd_soc_dai_link rockchip_dais[] = {
+   [DAILINK_CDNDP] = {
+   .name = "DP",
+   .stream_name = "DP PCM",
+   .codec_dai_name = "i2s-hifi",
+   .ops = _sound_cdndp_ops,
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
[DAILINK_DA7219] = {
.name = "DA7219",
.stream_name = "DA7219 PCM",
@@ -311,7 +364,7 @@ static int rockchip_sound_codec_node_match(struct 
device_node *np_codec)
 static int rockchip_sound_of_parse_dais(struct device *dev,
struct snd_soc_card *card)
 {
-   struct device_node *np_cpu;
+   struct device_node *np_cpu, *np_cpu0, *np_cpu1;
struct device_node *np_codec;
struct snd_soc_dai_link *dai;
int i, index;
@@ -321,7 +374,8 @@ static int rockchip_sound_of_parse_dais(struct device *dev,
if (!card->dai_link)
return -ENOMEM;
 
-   np_cpu = of_parse_phandle(dev->of_node, "rockchip,cpu", 0);
+   np_cpu0 = of_parse_phandle(dev->of_node, "rockchip,cpu", 0);
+   np_cpu1 = of_parse_phandle(dev->of_node, "rockchip,cpu", 1);
 
card->num_links = 0;
for (i = 0; i < ARRAY_SIZE(rockchip_dais); i++) {
@@ -337,6 +391,7 @@ static int rockchip_sound_of_parse_dais(struct device *dev,
if (index < 0)
continue;
 
+   np_cpu = (index == DAILINK_CDNDP) ? np_cpu1 : np_cpu0;
if (!np_cpu) {
dev_err(dev, "Missing 'rockchip,cpu' for %s\n",
  

Re: [PATCH v2 1/3] ASoC: rockchip: Parse dai links from dts

[jeffy]

Hi Matthias,

On 08/17/2017 07:50 AM, Matthias Kaehlcke wrote:

El Thu, Aug 17, 2017 at 06:55:20AM +0800 jeffy ha dit:


hi matthias,

thanks for your suggestion.

On 08/17/2017 05:59 AM, Matthias Kaehlcke wrote:

El Thu, Aug 10, 2017 at 12:54:56PM +0800 Jeffy Chen ha dit:


Refactor rockchip_sound_probe, parse dai links from dts instead of
hard coding them.

Mark doesn't seem to be overly convinced that 'rockchip,codec-names'
is a good idea (https://lkml.org/lkml/2017/8/10/511).

How about using something like this instead:

static const char *dailink_compat[] = {
[DAILINK_MAX98357A] = "maxim,max98357a",
[DAILINK_RT5514] = "realtek,rt5514",
[DAILINK_DA7219] = "dlg,da7219",
};

i've thought about this too, but i'm working on converting rt5514
dsp(spi) from codec name matching to of_node, and it would have the
same compatible with rt5514(i2c)


Bummer!

I wonder if a relatively inoffensive DT hack would be an appropriate
solution in this case, since the conflicting compatible string is a
somewhat special case and this change only affects the DT and the
driver/glue of a specific device (family).

The hack would consist in adding an additional 'compatible' entry to
the DT entry of the codec, which is ignored by the rt5514 driver, and
only used by the sound glue to identify it:

--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -671,7 +671,7 @@ ap_i2c_mic:  {
 i2c-scl-rising-time-ns = <300>;

 headsetcodec: rt5514@57 {
-   compatible = "realtek,rt5514";
+   compatible = "realtek,rt5514", "realtek,rt5514-i2c";


And then use "realtek,rt5514-i2c" in dailink_compat.

this should work, i'll do that in new version, thanks.



Mark, would you prefer a hack like this over the list of codec names
or do you have any other suggestions?

Matthias

Re: [PATCH v2 1/3] ASoC: rockchip: Parse dai links from dts

[jeffy]

Hi Matthias,

On 08/17/2017 07:50 AM, Matthias Kaehlcke wrote:

El Thu, Aug 17, 2017 at 06:55:20AM +0800 jeffy ha dit:


hi matthias,

thanks for your suggestion.

On 08/17/2017 05:59 AM, Matthias Kaehlcke wrote:

El Thu, Aug 10, 2017 at 12:54:56PM +0800 Jeffy Chen ha dit:


Refactor rockchip_sound_probe, parse dai links from dts instead of
hard coding them.

Mark doesn't seem to be overly convinced that 'rockchip,codec-names'
is a good idea (https://lkml.org/lkml/2017/8/10/511).

How about using something like this instead:

static const char *dailink_compat[] = {
[DAILINK_MAX98357A] = "maxim,max98357a",
[DAILINK_RT5514] = "realtek,rt5514",
[DAILINK_DA7219] = "dlg,da7219",
};

i've thought about this too, but i'm working on converting rt5514
dsp(spi) from codec name matching to of_node, and it would have the
same compatible with rt5514(i2c)


Bummer!

I wonder if a relatively inoffensive DT hack would be an appropriate
solution in this case, since the conflicting compatible string is a
somewhat special case and this change only affects the DT and the
driver/glue of a specific device (family).

The hack would consist in adding an additional 'compatible' entry to
the DT entry of the codec, which is ignored by the rt5514 driver, and
only used by the sound glue to identify it:

--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -671,7 +671,7 @@ ap_i2c_mic:  {
 i2c-scl-rising-time-ns = <300>;

 headsetcodec: rt5514@57 {
-   compatible = "realtek,rt5514";
+   compatible = "realtek,rt5514", "realtek,rt5514-i2c";


And then use "realtek,rt5514-i2c" in dailink_compat.

this should work, i'll do that in new version, thanks.



Mark, would you prefer a hack like this over the list of codec names
or do you have any other suggestions?

Matthias

[PATCH v3 7/9] ASoC: rockchip: Add support for DP codec

[Jeffy Chen]

Add support for optional cdn dp codec.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 sound/soc/rockchip/Kconfig|  1 +
 sound/soc/rockchip/rk3399_gru_sound.c | 59 +--
 2 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index c84487805876..8f0d0d8d34e6 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -68,6 +68,7 @@ config SND_SOC_RK3399_GRU_SOUND
select SND_SOC_RT5514
select SND_SOC_DA7219
select SND_SOC_RT5514_SPI
+   select SND_SOC_HDMI_CODEC
help
  Say Y or M here if you want to add support multiple codecs for SoC
  audio on Rockchip RK3399 GRU boards.
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index d532336871d7..8ffae1934b94 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -223,6 +223,45 @@ static int rockchip_sound_da7219_init(struct 
snd_soc_pcm_runtime *rtd)
return 0;
 }
 
+static int rockchip_sound_cdndp_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+   struct snd_soc_dai *codec_dai = rtd->codec_dai;
+   int mclk, ret;
+
+   /* in bypass mode, the mclk has to be one of the frequencies below */
+   switch (params_rate(params)) {
+   case 8000:
+   case 16000:
+   case 24000:
+   case 32000:
+   case 48000:
+   case 64000:
+   case 96000:
+   mclk = 12288000;
+   break;
+   case 11025:
+   case 22050:
+   case 44100:
+   case 88200:
+   mclk = 11289600;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk,
+SND_SOC_CLOCK_OUT);
+   if (ret < 0) {
+   dev_err(codec_dai->dev, "Can't set cpu clock out %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct snd_soc_ops rockchip_sound_max98357a_ops = {
.hw_params = rockchip_sound_max98357a_hw_params,
 };
@@ -235,6 +274,10 @@ static const struct snd_soc_ops rockchip_sound_da7219_ops 
= {
.hw_params = rockchip_sound_da7219_hw_params,
 };
 
+static struct snd_soc_ops rockchip_sound_cdndp_ops = {
+   .hw_params = rockchip_sound_cdndp_hw_params,
+};
+
 static struct snd_soc_card rockchip_sound_card = {
.name = "rk3399-gru-sound",
.owner = THIS_MODULE,
@@ -247,6 +290,7 @@ static struct snd_soc_card rockchip_sound_card = {
 };
 
 enum {
+   DAILINK_CDNDP,
DAILINK_DA7219,
DAILINK_MAX98357A,
DAILINK_RT5514,
@@ -254,6 +298,7 @@ enum {
 };
 
 static const char * const dailink_compat[] = {
+   [DAILINK_CDNDP] = "rockchip,rk3399-cdn-dp",
[DAILINK_DA7219] = "dlg,da7219",
[DAILINK_MAX98357A] = "maxim,max98357a",
[DAILINK_RT5514] = "realtek,rt5514-i2c",
@@ -261,6 +306,14 @@ static const char * const dailink_compat[] = {
 };
 
 static const struct snd_soc_dai_link rockchip_dais[] = {
+   [DAILINK_CDNDP] = {
+   .name = "DP",
+   .stream_name = "DP PCM",
+   .codec_dai_name = "i2s-hifi",
+   .ops = _sound_cdndp_ops,
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
[DAILINK_DA7219] = {
.name = "DA7219",
.stream_name = "DA7219 PCM",
@@ -311,7 +364,7 @@ static int rockchip_sound_codec_node_match(struct 
device_node *np_codec)
 static int rockchip_sound_of_parse_dais(struct device *dev,
struct snd_soc_card *card)
 {
-   struct device_node *np_cpu;
+   struct device_node *np_cpu, *np_cpu0, *np_cpu1;
struct device_node *np_codec;
struct snd_soc_dai_link *dai;
int i, index;
@@ -321,7 +374,8 @@ static int rockchip_sound_of_parse_dais(struct device *dev,
if (!card->dai_link)
return -ENOMEM;
 
-   np_cpu = of_parse_phandle(dev->of_node, "rockchip,cpu", 0);
+   np_cpu0 = of_parse_phandle(dev->of_node, "rockchip,cpu", 0);
+   np_cpu1 = of_parse_phandle(dev->of_node, "rockchip,cpu", 1);
 
card->num_links = 0;
for (i = 0; i < ARRAY_SIZE(rockchip_dais); i++) {
@@ -337,6 +391,7 @@ static int rockchip_sound_of_parse_dais(struct device *dev,
if (index < 0)
continue;
 
+   np_cpu = (index == DAILINK_CDNDP) ? np_cpu1 : np_cpu0;
if (!np_cpu) {
dev_err(dev, "Missing 'rockchip,cpu' for %s\n",

[PATCH v3 3/9] ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp

[Jeffy Chen]

Currently we are using codec name for rt5514 dsp dai link, use codec
of_node instead.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 sound/soc/rockchip/rk3399_gru_sound.c | 34 ++
 1 file changed, 2 insertions(+), 32 deletions(-)

diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 70876d3c34e6..9b7e28703bfb 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -242,8 +242,6 @@ enum {
DAILINK_RT5514_DSP,
 };
 
-#define DAILINK_ENTITIES   (DAILINK_DA7219 + 1)
-
 static struct snd_soc_dai_link rockchip_dailinks[] = {
[DAILINK_MAX98357A] = {
.name = "MAX98357A",
@@ -277,8 +275,7 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
[DAILINK_RT5514_DSP] = {
.name = "RT5514 DSP",
.stream_name = "Wake on Voice",
-   .codec_name = "snd-soc-dummy",
-   .codec_dai_name = "snd-soc-dummy-dai",
+   .codec_dai_name = "rt5514-dsp-cpu-dai",
},
 };
 
@@ -295,17 +292,10 @@ static struct snd_soc_card rockchip_sound_card = {
.num_controls = ARRAY_SIZE(rockchip_controls),
 };
 
-static int rockchip_sound_match_stub(struct device *dev, void *data)
-{
-   return 1;
-}
-
 static int rockchip_sound_probe(struct platform_device *pdev)
 {
struct snd_soc_card *card = _sound_card;
struct device_node *cpu_node;
-   struct device *dev;
-   struct device_driver *drv;
int i, ret;
 
cpu_node = of_parse_phandle(pdev->dev.of_node, "rockchip,cpu", 0);
@@ -314,7 +304,7 @@ static int rockchip_sound_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
-   for (i = 0; i < DAILINK_ENTITIES; i++) {
+   for (i = 0; i < ARRAY_SIZE(rockchip_dailinks); i++) {
rockchip_dailinks[i].platform_of_node = cpu_node;
rockchip_dailinks[i].cpu_of_node = cpu_node;
 
@@ -327,26 +317,6 @@ static int rockchip_sound_probe(struct platform_device 
*pdev)
}
}
 
-   /**
-* To acquire the spi driver of the rt5514 and set the dai-links names
-* for soc_bind_dai_link
-*/
-   drv = driver_find("rt5514", _bus_type);
-   if (!drv) {
-   dev_err(>dev, "Can not find the rt5514 driver at the spi 
bus\n");
-   return -EINVAL;
-   }
-
-   dev = driver_find_device(drv, NULL, NULL, rockchip_sound_match_stub);
-   if (!dev) {
-   dev_err(>dev, "Can not find the rt5514 device\n");
-   return -ENODEV;
-   }
-
-   rockchip_dailinks[DAILINK_RT5514_DSP].cpu_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
-   rockchip_dailinks[DAILINK_RT5514_DSP].cpu_dai_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
-   rockchip_dailinks[DAILINK_RT5514_DSP].platform_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
-
card->dev = >dev;
platform_set_drvdata(pdev, card);
 
-- 
2.11.0

[PATCH v3 5/9] arm64: dts: rockchip: Update rt5514 devices' compatible for Gru

[Jeffy Chen]

Currently the rt5514 i2c driver and rt5514 spi driver are using the same
compatible string.

Add additional unused compatible strings to identify them for Gru
boards.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 2713129722a1..275ccf64dfb9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -611,7 +611,7 @@ ap_i2c_mic:  {
i2c-scl-rising-time-ns = <300>;
 
headsetcodec: rt5514@57 {
-   compatible = "realtek,rt5514";
+   compatible = "realtek,rt5514", "realtek,rt5514-i2c";
reg = <0x57>;
interrupt-parent = <>;
interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
@@ -825,7 +825,7 @@ ap_i2c_audio:  {
status = "okay";
 
wacky_spi_audio: spi2@0 {
-   compatible = "realtek,rt5514";
+   compatible = "realtek,rt5514", "realtek,rt5514-spi";
reg = <0>;
 
/* May run faster once verified. */
-- 
2.11.0

[PATCH v3 3/9] ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp

[Jeffy Chen]

Currently we are using codec name for rt5514 dsp dai link, use codec
of_node instead.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 sound/soc/rockchip/rk3399_gru_sound.c | 34 ++
 1 file changed, 2 insertions(+), 32 deletions(-)

diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 70876d3c34e6..9b7e28703bfb 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -242,8 +242,6 @@ enum {
DAILINK_RT5514_DSP,
 };
 
-#define DAILINK_ENTITIES   (DAILINK_DA7219 + 1)
-
 static struct snd_soc_dai_link rockchip_dailinks[] = {
[DAILINK_MAX98357A] = {
.name = "MAX98357A",
@@ -277,8 +275,7 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
[DAILINK_RT5514_DSP] = {
.name = "RT5514 DSP",
.stream_name = "Wake on Voice",
-   .codec_name = "snd-soc-dummy",
-   .codec_dai_name = "snd-soc-dummy-dai",
+   .codec_dai_name = "rt5514-dsp-cpu-dai",
},
 };
 
@@ -295,17 +292,10 @@ static struct snd_soc_card rockchip_sound_card = {
.num_controls = ARRAY_SIZE(rockchip_controls),
 };
 
-static int rockchip_sound_match_stub(struct device *dev, void *data)
-{
-   return 1;
-}
-
 static int rockchip_sound_probe(struct platform_device *pdev)
 {
struct snd_soc_card *card = _sound_card;
struct device_node *cpu_node;
-   struct device *dev;
-   struct device_driver *drv;
int i, ret;
 
cpu_node = of_parse_phandle(pdev->dev.of_node, "rockchip,cpu", 0);
@@ -314,7 +304,7 @@ static int rockchip_sound_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
-   for (i = 0; i < DAILINK_ENTITIES; i++) {
+   for (i = 0; i < ARRAY_SIZE(rockchip_dailinks); i++) {
rockchip_dailinks[i].platform_of_node = cpu_node;
rockchip_dailinks[i].cpu_of_node = cpu_node;
 
@@ -327,26 +317,6 @@ static int rockchip_sound_probe(struct platform_device 
*pdev)
}
}
 
-   /**
-* To acquire the spi driver of the rt5514 and set the dai-links names
-* for soc_bind_dai_link
-*/
-   drv = driver_find("rt5514", _bus_type);
-   if (!drv) {
-   dev_err(>dev, "Can not find the rt5514 driver at the spi 
bus\n");
-   return -EINVAL;
-   }
-
-   dev = driver_find_device(drv, NULL, NULL, rockchip_sound_match_stub);
-   if (!dev) {
-   dev_err(>dev, "Can not find the rt5514 device\n");
-   return -ENODEV;
-   }
-
-   rockchip_dailinks[DAILINK_RT5514_DSP].cpu_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
-   rockchip_dailinks[DAILINK_RT5514_DSP].cpu_dai_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
-   rockchip_dailinks[DAILINK_RT5514_DSP].platform_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
-
card->dev = >dev;
platform_set_drvdata(pdev, card);
 
-- 
2.11.0

[PATCH v3 5/9] arm64: dts: rockchip: Update rt5514 devices' compatible for Gru

[Jeffy Chen]

Currently the rt5514 i2c driver and rt5514 spi driver are using the same
compatible string.

Add additional unused compatible strings to identify them for Gru
boards.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 2713129722a1..275ccf64dfb9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -611,7 +611,7 @@ ap_i2c_mic:  {
i2c-scl-rising-time-ns = <300>;
 
headsetcodec: rt5514@57 {
-   compatible = "realtek,rt5514";
+   compatible = "realtek,rt5514", "realtek,rt5514-i2c";
reg = <0x57>;
interrupt-parent = <>;
interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
@@ -825,7 +825,7 @@ ap_i2c_audio:  {
status = "okay";
 
wacky_spi_audio: spi2@0 {
-   compatible = "realtek,rt5514";
+   compatible = "realtek,rt5514", "realtek,rt5514-spi";
reg = <0>;
 
/* May run faster once verified. */
-- 
2.11.0

[PATCH v3 2/9] ASoC: rockchip: Remove obsolete dmic-delay

[Jeffy Chen]

This property is no longer used.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 .../bindings/sound/rockchip,rk3399-gru-sound.txt   |  7 ---
 sound/soc/rockchip/rk3399_gru_sound.c  | 14 --
 2 files changed, 21 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
index eac91db07178..f19b6c830a34 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
@@ -6,17 +6,10 @@ Required properties:
   connected to the codecs
 - rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
 
-Optional properties:
-- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
-  If this option is specified, which means it's required dmic need
-  delay for DMIC to ready so that rt5514 can avoid recording before
-  DMIC send valid data
-
 Example:
 
 sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = <>;
rockchip,codec = <  >;
-   dmic-wakeup-delay-ms = <20>;
 };
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 3475c61a5fa0..70876d3c34e6 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -38,8 +38,6 @@
 
 #define SOUND_FS   256
 
-static unsigned int rt5514_dmic_delay;
-
 static struct snd_soc_jack rockchip_sound_jack;
 
 static const struct snd_soc_dapm_widget rockchip_dapm_widgets[] = {
@@ -125,9 +123,6 @@ static int rockchip_sound_rt5514_hw_params(struct 
snd_pcm_substream *substream,
return ret;
}
 
-   /* Wait for DMIC stable */
-   msleep(rt5514_dmic_delay);
-
return 0;
 }
 
@@ -348,15 +343,6 @@ static int rockchip_sound_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
-   /* Set DMIC delay */
-   ret = device_property_read_u32(>dev, "dmic-delay",
-   _dmic_delay);
-   if (ret) {
-   rt5514_dmic_delay = 0;
-   dev_dbg(>dev,
-   "no optional property 'dmic-delay' found, default: no 
delay\n");
-   }
-
rockchip_dailinks[DAILINK_RT5514_DSP].cpu_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
rockchip_dailinks[DAILINK_RT5514_DSP].cpu_dai_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
rockchip_dailinks[DAILINK_RT5514_DSP].platform_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
-- 
2.11.0

[PATCH v3 2/9] ASoC: rockchip: Remove obsolete dmic-delay

[Jeffy Chen]

This property is no longer used.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 .../bindings/sound/rockchip,rk3399-gru-sound.txt   |  7 ---
 sound/soc/rockchip/rk3399_gru_sound.c  | 14 --
 2 files changed, 21 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
index eac91db07178..f19b6c830a34 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
@@ -6,17 +6,10 @@ Required properties:
   connected to the codecs
 - rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
 
-Optional properties:
-- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
-  If this option is specified, which means it's required dmic need
-  delay for DMIC to ready so that rt5514 can avoid recording before
-  DMIC send valid data
-
 Example:
 
 sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = <>;
rockchip,codec = <  >;
-   dmic-wakeup-delay-ms = <20>;
 };
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 3475c61a5fa0..70876d3c34e6 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -38,8 +38,6 @@
 
 #define SOUND_FS   256
 
-static unsigned int rt5514_dmic_delay;
-
 static struct snd_soc_jack rockchip_sound_jack;
 
 static const struct snd_soc_dapm_widget rockchip_dapm_widgets[] = {
@@ -125,9 +123,6 @@ static int rockchip_sound_rt5514_hw_params(struct 
snd_pcm_substream *substream,
return ret;
}
 
-   /* Wait for DMIC stable */
-   msleep(rt5514_dmic_delay);
-
return 0;
 }
 
@@ -348,15 +343,6 @@ static int rockchip_sound_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
-   /* Set DMIC delay */
-   ret = device_property_read_u32(>dev, "dmic-delay",
-   _dmic_delay);
-   if (ret) {
-   rt5514_dmic_delay = 0;
-   dev_dbg(>dev,
-   "no optional property 'dmic-delay' found, default: no 
delay\n");
-   }
-
rockchip_dailinks[DAILINK_RT5514_DSP].cpu_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
rockchip_dailinks[DAILINK_RT5514_DSP].cpu_dai_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
rockchip_dailinks[DAILINK_RT5514_DSP].platform_name = 
kstrdup_const(dev_name(dev), GFP_KERNEL);
-- 
2.11.0

[PATCH v3 0/9] ASoC: rockchip: Parse dai links from dts

[Jeffy Chen]

Currently we are using a fixed list of dai links in the driver.
This serial of patches would let the driver parse dai links from
dts, so that we can make some of them optional for future boards.

Tested on my chromebook bob(with cros 4.4 kernel), it still works
after disabled rt5514 codecs in the dts.


Changes in v3:
Use compatible to match audio codecs
-- Suggested-by Matthias Kaehlcke 

Changes in v2:
Let rockchip,codec-names be a required property, because we plan to
add more supported codecs to the fixed dai link list in the driver.

Jeffy Chen (9):
  ASoC: rt5514: Switch to snd_soc_register_codec
  ASoC: rockchip: Remove obsolete dmic-delay
  ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp
  arm64: dts: rockchip: Add rt5514 dsp for Gru
  arm64: dts: rockchip: Update rt5514 devices' compatible for Gru
  ASoC: rockchip: Parse dai links from dts
  ASoC: rockchip: Add support for DP codec
  ASoC: rockchip: Add support for DMIC codec
  dt-bindings: ASoC: rockchip: Update description of rockchip,codec

 .../bindings/sound/rockchip,rk3399-gru-sound.txt   |   9 +-
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   |   7 +-
 sound/soc/codecs/rt5514-spi.c  |  19 +-
 sound/soc/rockchip/Kconfig |   2 +
 sound/soc/rockchip/rk3399_gru_sound.c  | 263 ++---
 5 files changed, 196 insertions(+), 104 deletions(-)

-- 
2.11.0

[PATCH v3 1/9] ASoC: rt5514: Switch to snd_soc_register_codec

[Jeffy Chen]

Currently we are using devm_snd_soc_register_component, which would
use legacy dai name.

Switch to snd_soc_register_codec to use dai driver name.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 sound/soc/codecs/rt5514-spi.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/rt5514-spi.c b/sound/soc/codecs/rt5514-spi.c
index 640193d845be..ad6bc51dd82a 100644
--- a/sound/soc/codecs/rt5514-spi.c
+++ b/sound/soc/codecs/rt5514-spi.c
@@ -277,8 +277,10 @@ static struct snd_soc_platform_driver rt5514_spi_platform 
= {
.ops = _spi_pcm_ops,
 };
 
-static const struct snd_soc_component_driver rt5514_spi_dai_component = {
-   .name   = "rt5514-spi-dai",
+static const struct snd_soc_codec_driver rt5514_spi_dai_codec = {
+   .component_driver = {
+   .name = "rt5514-spi-dai",
+   },
 };
 
 /**
@@ -426,9 +428,8 @@ static int rt5514_spi_probe(struct spi_device *spi)
return ret;
}
 
-   ret = devm_snd_soc_register_component(>dev,
- _spi_dai_component,
- _spi_dai, 1);
+   ret = snd_soc_register_codec(>dev, _spi_dai_codec,
+_spi_dai, 1);
if (ret < 0) {
dev_err(>dev, "Failed to register component.\n");
return ret;
@@ -437,6 +438,13 @@ static int rt5514_spi_probe(struct spi_device *spi)
return 0;
 }
 
+static int rt5514_spi_remove(struct spi_device *spi)
+{
+   snd_soc_unregister_codec(>dev);
+
+   return 0;
+}
+
 static const struct of_device_id rt5514_of_match[] = {
{ .compatible = "realtek,rt5514", },
{},
@@ -449,6 +457,7 @@ static struct spi_driver rt5514_spi_driver = {
.of_match_table = of_match_ptr(rt5514_of_match),
},
.probe = rt5514_spi_probe,
+   .remove = rt5514_spi_remove,
 };
 module_spi_driver(rt5514_spi_driver);
 
-- 
2.11.0

[PATCH v3 0/9] ASoC: rockchip: Parse dai links from dts

[Jeffy Chen]

Currently we are using a fixed list of dai links in the driver.
This serial of patches would let the driver parse dai links from
dts, so that we can make some of them optional for future boards.

Tested on my chromebook bob(with cros 4.4 kernel), it still works
after disabled rt5514 codecs in the dts.


Changes in v3:
Use compatible to match audio codecs
-- Suggested-by Matthias Kaehlcke 

Changes in v2:
Let rockchip,codec-names be a required property, because we plan to
add more supported codecs to the fixed dai link list in the driver.

Jeffy Chen (9):
  ASoC: rt5514: Switch to snd_soc_register_codec
  ASoC: rockchip: Remove obsolete dmic-delay
  ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp
  arm64: dts: rockchip: Add rt5514 dsp for Gru
  arm64: dts: rockchip: Update rt5514 devices' compatible for Gru
  ASoC: rockchip: Parse dai links from dts
  ASoC: rockchip: Add support for DP codec
  ASoC: rockchip: Add support for DMIC codec
  dt-bindings: ASoC: rockchip: Update description of rockchip,codec

 .../bindings/sound/rockchip,rk3399-gru-sound.txt   |   9 +-
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi   |   7 +-
 sound/soc/codecs/rt5514-spi.c  |  19 +-
 sound/soc/rockchip/Kconfig |   2 +
 sound/soc/rockchip/rk3399_gru_sound.c  | 263 ++---
 5 files changed, 196 insertions(+), 104 deletions(-)

-- 
2.11.0

[PATCH v3 1/9] ASoC: rt5514: Switch to snd_soc_register_codec

[Jeffy Chen]

Currently we are using devm_snd_soc_register_component, which would
use legacy dai name.

Switch to snd_soc_register_codec to use dai driver name.

Signed-off-by: Jeffy Chen 
---

Changes in v3: None
Changes in v2: None

 sound/soc/codecs/rt5514-spi.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/rt5514-spi.c b/sound/soc/codecs/rt5514-spi.c
index 640193d845be..ad6bc51dd82a 100644
--- a/sound/soc/codecs/rt5514-spi.c
+++ b/sound/soc/codecs/rt5514-spi.c
@@ -277,8 +277,10 @@ static struct snd_soc_platform_driver rt5514_spi_platform 
= {
.ops = _spi_pcm_ops,
 };
 
-static const struct snd_soc_component_driver rt5514_spi_dai_component = {
-   .name   = "rt5514-spi-dai",
+static const struct snd_soc_codec_driver rt5514_spi_dai_codec = {
+   .component_driver = {
+   .name = "rt5514-spi-dai",
+   },
 };
 
 /**
@@ -426,9 +428,8 @@ static int rt5514_spi_probe(struct spi_device *spi)
return ret;
}
 
-   ret = devm_snd_soc_register_component(>dev,
- _spi_dai_component,
- _spi_dai, 1);
+   ret = snd_soc_register_codec(>dev, _spi_dai_codec,
+_spi_dai, 1);
if (ret < 0) {
dev_err(>dev, "Failed to register component.\n");
return ret;
@@ -437,6 +438,13 @@ static int rt5514_spi_probe(struct spi_device *spi)
return 0;
 }
 
+static int rt5514_spi_remove(struct spi_device *spi)
+{
+   snd_soc_unregister_codec(>dev);
+
+   return 0;
+}
+
 static const struct of_device_id rt5514_of_match[] = {
{ .compatible = "realtek,rt5514", },
{},
@@ -449,6 +457,7 @@ static struct spi_driver rt5514_spi_driver = {
.of_match_table = of_match_ptr(rt5514_of_match),
},
.probe = rt5514_spi_probe,
+   .remove = rt5514_spi_remove,
 };
 module_spi_driver(rt5514_spi_driver);
 
-- 
2.11.0

Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

[Daniel Micay]

On Wed, 2017-08-16 at 23:31 -0400, Theodore Ts'o wrote:
> On Wed, Aug 16, 2017 at 04:14:58PM -0700, Laura Abbott wrote:
> > From: Daniel Micay 
> > 
> > Existing Android bootloaders usually pass data useful as early
> > entropy
> > on the kernel command-line. It may also be the case on other
> > embedded
> > systems.
> 
> May I suggest a slight adjustment to the beginning commit description?
> 
>Feed the boot command-line as to the /dev/random entropy pool
> 
>Existing Android bootloaders usually pass data which may not be
>known by an external attacker on the kernel command-line.  It may
>also be the case on other embedded systems.  Sample command-line
>from a Google Pixel running CopperheadOS
> 
> The idea here is to if anything, err on the side of under-promising
> the amount of security we can guarantee that this technique will
> provide.  For example, how hard is it really for an attacker who has
> an APK installed locally to get the device serial number?  Or the OS
> version?  And how much variability is there in the bootloader stages
> in milliseconds?

The serial number is currently accessible to local apps up until Android
7.x so it doesn't have value if the adversary has local access. Access
to it without the READ_PHONE_STATE permission is being removed for apps
targeting Android 8.0 and will presumably be restructed for all apps at
some point in the future:

https://android-developers.googleblog.com/2017/04/changes-to-device-identifiers-in.html

Some bootloader stages vary a bit in time each boot. There's not much
variance or measurement precision so there's only a small amount of
entropy from this. The ones that consistently vary in timing do so
independently from each other so that helps a bit. Also worth noting
that before Android 8.0+, local apps can access the boot times since
it's written to a system property. After Android 8.0+, all that stuff is
inaccessible to them (no permission to get them) since there's a
whitelisting model for system property access.

> I think we should definitely do this.  So this is more of a request to
> be very careful what we promise in the commit description, not an
> objection to the change itself.

I did say 'external attacker' but it could be made clearer. It's
primarily aimed at getting a tiny bit of extra entropy for the kernel
stack canary and other probabilistic exploit mitigations set up in early
boot. On non-x86 archs, i.e. 99.9% of Android devices, the kernel stack
canary remains the same after it's set up in that early boot code.

Android devices almost all have a hardware RNG and Android init blocks
until a fair bit of data is read from it along with restoring entropy
that's regularly saved while running, but unfortunately that's not
available at this point in the boot process.

The kernel could save / restore entropy using pstore (which at least
Nexus / Pixel devices have - not sure about others). I don't know how
early that could feasibly be done. Ideally it would do that combined
with early usage of the hwrng.

Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

[Daniel Micay]

On Wed, 2017-08-16 at 23:31 -0400, Theodore Ts'o wrote:
> On Wed, Aug 16, 2017 at 04:14:58PM -0700, Laura Abbott wrote:
> > From: Daniel Micay 
> > 
> > Existing Android bootloaders usually pass data useful as early
> > entropy
> > on the kernel command-line. It may also be the case on other
> > embedded
> > systems.
> 
> May I suggest a slight adjustment to the beginning commit description?
> 
>Feed the boot command-line as to the /dev/random entropy pool
> 
>Existing Android bootloaders usually pass data which may not be
>known by an external attacker on the kernel command-line.  It may
>also be the case on other embedded systems.  Sample command-line
>from a Google Pixel running CopperheadOS
> 
> The idea here is to if anything, err on the side of under-promising
> the amount of security we can guarantee that this technique will
> provide.  For example, how hard is it really for an attacker who has
> an APK installed locally to get the device serial number?  Or the OS
> version?  And how much variability is there in the bootloader stages
> in milliseconds?

The serial number is currently accessible to local apps up until Android
7.x so it doesn't have value if the adversary has local access. Access
to it without the READ_PHONE_STATE permission is being removed for apps
targeting Android 8.0 and will presumably be restructed for all apps at
some point in the future:

https://android-developers.googleblog.com/2017/04/changes-to-device-identifiers-in.html

Some bootloader stages vary a bit in time each boot. There's not much
variance or measurement precision so there's only a small amount of
entropy from this. The ones that consistently vary in timing do so
independently from each other so that helps a bit. Also worth noting
that before Android 8.0+, local apps can access the boot times since
it's written to a system property. After Android 8.0+, all that stuff is
inaccessible to them (no permission to get them) since there's a
whitelisting model for system property access.

> I think we should definitely do this.  So this is more of a request to
> be very careful what we promise in the commit description, not an
> objection to the change itself.

I did say 'external attacker' but it could be made clearer. It's
primarily aimed at getting a tiny bit of extra entropy for the kernel
stack canary and other probabilistic exploit mitigations set up in early
boot. On non-x86 archs, i.e. 99.9% of Android devices, the kernel stack
canary remains the same after it's set up in that early boot code.

Android devices almost all have a hardware RNG and Android init blocks
until a fair bit of data is read from it along with restoring entropy
that's regularly saved while running, but unfortunately that's not
available at this point in the boot process.

The kernel could save / restore entropy using pstore (which at least
Nexus / Pixel devices have - not sure about others). I don't know how
early that could feasibly be done. Ideally it would do that combined
with early usage of the hwrng.

Re: [PATCH] samples: Unrename SECCOMP_RET_KILL

[James Morris]

On Wed, 16 Aug 2017, Kees Cook wrote:

> Since samples can still be built before header installs, avoid the
> cosmetic renaming of SECCOMP_RET_KILL to avoid build failures in -next.
> 
> Cc: Stephen Rothwell 
> Signed-off-by: Kees Cook 
> ---
> Hi James, this should fix the samples build failure seen during -next
> cross compiles.

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next

-- 
James Morris

Re: [PATCH] samples: Unrename SECCOMP_RET_KILL

[James Morris]

On Wed, 16 Aug 2017, Kees Cook wrote:

> Since samples can still be built before header installs, avoid the
> cosmetic renaming of SECCOMP_RET_KILL to avoid build failures in -next.
> 
> Cc: Stephen Rothwell 
> Signed-off-by: Kees Cook 
> ---
> Hi James, this should fix the samples build failure seen during -next
> cross compiles.

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next

-- 
James Morris

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

[Stephen Rothwell]

Hi all,

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

  arch/x86/entry/entry_64.S

between commit:

  UNWIND_HINT_IRET_REGS ("x86/entry/64: Add unwind hint annotations")

from the tip tree and commit:

  ad5b8c4ba323 ("xen: get rid of paravirt op adjust_exception_frame")

from the xen-tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/entry/entry_64.S
index ca0b250eefc4,67fefaf21312..
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@@ -978,15 -891,17 +977,15 @@@ bad_gs
  ENTRY(do_softirq_own_stack)
pushq   %rbp
mov %rsp, %rbp
 -  inclPER_CPU_VAR(irq_count)
 -  cmove   PER_CPU_VAR(irq_stack_ptr), %rsp
 -  push%rbp/* frame pointer backlink */
 +  ENTER_IRQ_STACK regs=0 old_rsp=%r11
call__do_softirq
 +  LEAVE_IRQ_STACK regs=0
leaveq
 -  declPER_CPU_VAR(irq_count)
ret
 -END(do_softirq_own_stack)
 +ENDPROC(do_softirq_own_stack)
  
  #ifdef CONFIG_XEN
- idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
+ idtentry hypervisor_callback xen_do_hypervisor_callback has_error_code=0
  
  /*
   * A note on the "critical region" in our callback handler.
@@@ -1053,9 -967,6 +1052,7 @@@ ENTRY(xen_failsafe_callback
movq8(%rsp), %r11
addq$0x30, %rsp
pushq   $0  /* RIP */
-   pushq   %r11
-   pushq   %rcx
 +  UNWIND_HINT_IRET_REGS offset=8
jmp general_protection
  1:/* Segment mismatch => Category 1 (Bad segment). Retry the IRET. */
movq(%rsp), %rcx
@@@ -1251,20 -1156,8 +1247,9 @@@ ENTRY(error_exit
  END(error_exit)
  
  /* Runs on exception stack */
+ /* XXX: broken on Xen PV */
  ENTRY(nmi)
 +  UNWIND_HINT_IRET_REGS
-   /*
-* Fix up the exception frame if we're on Xen.
-* PARAVIRT_ADJUST_EXCEPTION_FRAME is guaranteed to push at most
-* one value to the stack on native, so it may clobber the rdx
-* scratch slot, but it won't clobber any of the important
-* slots past it.
-*
-* Xen is a different story, because the Xen frame itself overlaps
-* the "NMI executing" variable.
-*/
-   PARAVIRT_ADJUST_EXCEPTION_FRAME
- 
/*
 * We allow breakpoints in NMIs. If a breakpoint occurs, then
 * the iretq it performs will take us out of NMI context.

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

[Stephen Rothwell]

Hi all,

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

  arch/x86/entry/entry_64.S

between commit:

  UNWIND_HINT_IRET_REGS ("x86/entry/64: Add unwind hint annotations")

from the tip tree and commit:

  ad5b8c4ba323 ("xen: get rid of paravirt op adjust_exception_frame")

from the xen-tip tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/entry/entry_64.S
index ca0b250eefc4,67fefaf21312..
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@@ -978,15 -891,17 +977,15 @@@ bad_gs
  ENTRY(do_softirq_own_stack)
pushq   %rbp
mov %rsp, %rbp
 -  inclPER_CPU_VAR(irq_count)
 -  cmove   PER_CPU_VAR(irq_stack_ptr), %rsp
 -  push%rbp/* frame pointer backlink */
 +  ENTER_IRQ_STACK regs=0 old_rsp=%r11
call__do_softirq
 +  LEAVE_IRQ_STACK regs=0
leaveq
 -  declPER_CPU_VAR(irq_count)
ret
 -END(do_softirq_own_stack)
 +ENDPROC(do_softirq_own_stack)
  
  #ifdef CONFIG_XEN
- idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
+ idtentry hypervisor_callback xen_do_hypervisor_callback has_error_code=0
  
  /*
   * A note on the "critical region" in our callback handler.
@@@ -1053,9 -967,6 +1052,7 @@@ ENTRY(xen_failsafe_callback
movq8(%rsp), %r11
addq$0x30, %rsp
pushq   $0  /* RIP */
-   pushq   %r11
-   pushq   %rcx
 +  UNWIND_HINT_IRET_REGS offset=8
jmp general_protection
  1:/* Segment mismatch => Category 1 (Bad segment). Retry the IRET. */
movq(%rsp), %rcx
@@@ -1251,20 -1156,8 +1247,9 @@@ ENTRY(error_exit
  END(error_exit)
  
  /* Runs on exception stack */
+ /* XXX: broken on Xen PV */
  ENTRY(nmi)
 +  UNWIND_HINT_IRET_REGS
-   /*
-* Fix up the exception frame if we're on Xen.
-* PARAVIRT_ADJUST_EXCEPTION_FRAME is guaranteed to push at most
-* one value to the stack on native, so it may clobber the rdx
-* scratch slot, but it won't clobber any of the important
-* slots past it.
-*
-* Xen is a different story, because the Xen frame itself overlaps
-* the "NMI executing" variable.
-*/
-   PARAVIRT_ADJUST_EXCEPTION_FRAME
- 
/*
 * We allow breakpoints in NMIs. If a breakpoint occurs, then
 * the iretq it performs will take us out of NMI context.

[PATCH][RFC v3] PM / Hibernate: Feed the wathdog when creating snapshot

[Chen Yu]

There is a problem that when counting the pages for creating
the hibernation snapshot will take significant amount of
time, especially on system with large memory. Since the counting
job is performed with irq disabled, this might lead to NMI lockup.
The following warning were found on a system with 1.5TB DRAM:

[ 1124.758184] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 1124.768721] OOM killer disabled.
[ 1124.847009] PM: Preallocating image memory...
[ 1139.392042] NMI watchdog: Watchdog detected hard LOCKUP on cpu 27
[ 1139.392076] CPU: 27 PID: 3128 Comm: systemd-sleep Not tainted 
4.13.0-0.rc2.git0.1.fc27.x86_64 #1
[ 1139.392077] task: 9f01971ac000 task.stack: b1a3f325c000
[ 1139.392083] RIP: 0010:memory_bm_find_bit+0xf4/0x100
[ 1139.392084] RSP: 0018:b1a3f325fc20 EFLAGS: 0006
[ 1139.392084] RAX:  RBX: 13b83000 RCX: 9fbe89caf000
[ 1139.392085] RDX: b1a3f325fc30 RSI: 3200 RDI: 9fbeae80
[ 1139.392085] RBP: b1a3f325fc40 R08: 13b8 R09: 9fbe89c54878
[ 1139.392085] R10: b1a3f325fc2c R11: 13b83200 R12: 0400
[ 1139.392086] R13: fd552e0c R14: 9fc1bffd31e0 R15: 0202
[ 1139.392086] FS:  7f3189704180() GS:9fbec8ec() 
knlGS:
[ 1139.392087] CS:  0010 DS:  ES:  CR0: 80050033
[ 1139.392087] CR2: 0085da0f7398 CR3: 01771cf9a000 CR4: 007406e0
[ 1139.392088] DR0:  DR1:  DR2: 
[ 1139.392088] DR3:  DR6: fffe0ff0 DR7: 0400
[ 1139.392088] PKRU: 5554
[ 1139.392089] Call Trace:
[ 1139.392092]  ? memory_bm_set_bit+0x29/0x60
[ 1139.392094]  swsusp_set_page_free+0x2b/0x30
[ 1139.392098]  mark_free_pages+0x147/0x1c0
[ 1139.392099]  count_data_pages+0x41/0xa0
[ 1139.392101]  hibernate_preallocate_memory+0x80/0x450
[ 1139.392102]  hibernation_snapshot+0x58/0x410
[ 1139.392103]  hibernate+0x17c/0x310
[ 1139.392104]  state_store+0xdf/0xf0
[ 1139.392107]  kobj_attr_store+0xf/0x20
[ 1139.392111]  sysfs_kf_write+0x37/0x40
[ 1139.392113]  kernfs_fop_write+0x11c/0x1a0
[ 1139.392117]  __vfs_write+0x37/0x170
[ 1139.392121]  ? handle_mm_fault+0xd8/0x230
[ 1139.392122]  vfs_write+0xb1/0x1a0
[ 1139.392123]  SyS_write+0x55/0xc0
[ 1139.392126]  entry_SYSCALL_64_fastpath+0x1a/0xa5

So avoid the NMI lockup by feeding the watchdog every 1000 pages.

Reported-by: Jan Filipcewicz 
Suggested-by: Michal Hocko 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Dan Williams 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Chen Yu 
---
 mm/page_alloc.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6d00f74..0266eb6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -66,6 +66,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -2531,11 +2532,14 @@ void drain_all_pages(struct zone *zone)
 
 #ifdef CONFIG_HIBERNATION
 
+/* Touch watchdog for every WD_INTERVAL_PAGE pages. */
+#define WD_INTERVAL_PAGE   1000
+
 void mark_free_pages(struct zone *zone)
 {
unsigned long pfn, max_zone_pfn;
unsigned long flags;
-   unsigned int order, t;
+   unsigned int order, t, page_num = 0;
struct page *page;
 
if (zone_is_empty(zone))
@@ -2548,6 +2552,9 @@ void mark_free_pages(struct zone *zone)
if (pfn_valid(pfn)) {
page = pfn_to_page(pfn);
 
+   if (!((page_num++) % WD_INTERVAL_PAGE))
+   touch_nmi_watchdog();
+
if (page_zone(page) != zone)
continue;
 
@@ -2555,14 +2562,19 @@ void mark_free_pages(struct zone *zone)
swsusp_unset_page_free(page);
}
 
+   page_num = 0;
+
for_each_migratetype_order(order, t) {
list_for_each_entry(page,
>free_area[order].free_list[t], lru) {
unsigned long i;
 
pfn = page_to_pfn(page);
-   for (i = 0; i < (1UL << order); i++)
+   for (i = 0; i < (1UL << order); i++) {
+   if (!((page_num++) % WD_INTERVAL_PAGE))
+   touch_nmi_watchdog();
swsusp_set_page_free(pfn_to_page(pfn + i));
+   }
}
}
spin_unlock_irqrestore(>lock, flags);
-- 
2.7.4

[PATCH][RFC v3] PM / Hibernate: Feed the wathdog when creating snapshot

[Chen Yu]

There is a problem that when counting the pages for creating
the hibernation snapshot will take significant amount of
time, especially on system with large memory. Since the counting
job is performed with irq disabled, this might lead to NMI lockup.
The following warning were found on a system with 1.5TB DRAM:

[ 1124.758184] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 1124.768721] OOM killer disabled.
[ 1124.847009] PM: Preallocating image memory...
[ 1139.392042] NMI watchdog: Watchdog detected hard LOCKUP on cpu 27
[ 1139.392076] CPU: 27 PID: 3128 Comm: systemd-sleep Not tainted 
4.13.0-0.rc2.git0.1.fc27.x86_64 #1
[ 1139.392077] task: 9f01971ac000 task.stack: b1a3f325c000
[ 1139.392083] RIP: 0010:memory_bm_find_bit+0xf4/0x100
[ 1139.392084] RSP: 0018:b1a3f325fc20 EFLAGS: 0006
[ 1139.392084] RAX:  RBX: 13b83000 RCX: 9fbe89caf000
[ 1139.392085] RDX: b1a3f325fc30 RSI: 3200 RDI: 9fbeae80
[ 1139.392085] RBP: b1a3f325fc40 R08: 13b8 R09: 9fbe89c54878
[ 1139.392085] R10: b1a3f325fc2c R11: 13b83200 R12: 0400
[ 1139.392086] R13: fd552e0c R14: 9fc1bffd31e0 R15: 0202
[ 1139.392086] FS:  7f3189704180() GS:9fbec8ec() 
knlGS:
[ 1139.392087] CS:  0010 DS:  ES:  CR0: 80050033
[ 1139.392087] CR2: 0085da0f7398 CR3: 01771cf9a000 CR4: 007406e0
[ 1139.392088] DR0:  DR1:  DR2: 
[ 1139.392088] DR3:  DR6: fffe0ff0 DR7: 0400
[ 1139.392088] PKRU: 5554
[ 1139.392089] Call Trace:
[ 1139.392092]  ? memory_bm_set_bit+0x29/0x60
[ 1139.392094]  swsusp_set_page_free+0x2b/0x30
[ 1139.392098]  mark_free_pages+0x147/0x1c0
[ 1139.392099]  count_data_pages+0x41/0xa0
[ 1139.392101]  hibernate_preallocate_memory+0x80/0x450
[ 1139.392102]  hibernation_snapshot+0x58/0x410
[ 1139.392103]  hibernate+0x17c/0x310
[ 1139.392104]  state_store+0xdf/0xf0
[ 1139.392107]  kobj_attr_store+0xf/0x20
[ 1139.392111]  sysfs_kf_write+0x37/0x40
[ 1139.392113]  kernfs_fop_write+0x11c/0x1a0
[ 1139.392117]  __vfs_write+0x37/0x170
[ 1139.392121]  ? handle_mm_fault+0xd8/0x230
[ 1139.392122]  vfs_write+0xb1/0x1a0
[ 1139.392123]  SyS_write+0x55/0xc0
[ 1139.392126]  entry_SYSCALL_64_fastpath+0x1a/0xa5

So avoid the NMI lockup by feeding the watchdog every 1000 pages.

Reported-by: Jan Filipcewicz 
Suggested-by: Michal Hocko 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Dan Williams 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Chen Yu 
---
 mm/page_alloc.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6d00f74..0266eb6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -66,6 +66,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -2531,11 +2532,14 @@ void drain_all_pages(struct zone *zone)
 
 #ifdef CONFIG_HIBERNATION
 
+/* Touch watchdog for every WD_INTERVAL_PAGE pages. */
+#define WD_INTERVAL_PAGE   1000
+
 void mark_free_pages(struct zone *zone)
 {
unsigned long pfn, max_zone_pfn;
unsigned long flags;
-   unsigned int order, t;
+   unsigned int order, t, page_num = 0;
struct page *page;
 
if (zone_is_empty(zone))
@@ -2548,6 +2552,9 @@ void mark_free_pages(struct zone *zone)
if (pfn_valid(pfn)) {
page = pfn_to_page(pfn);
 
+   if (!((page_num++) % WD_INTERVAL_PAGE))
+   touch_nmi_watchdog();
+
if (page_zone(page) != zone)
continue;
 
@@ -2555,14 +2562,19 @@ void mark_free_pages(struct zone *zone)
swsusp_unset_page_free(page);
}
 
+   page_num = 0;
+
for_each_migratetype_order(order, t) {
list_for_each_entry(page,
>free_area[order].free_list[t], lru) {
unsigned long i;
 
pfn = page_to_pfn(page);
-   for (i = 0; i < (1UL << order); i++)
+   for (i = 0; i < (1UL << order); i++) {
+   if (!((page_num++) % WD_INTERVAL_PAGE))
+   touch_nmi_watchdog();
swsusp_set_page_free(pfn_to_page(pfn + i));
+   }
}
}
spin_unlock_irqrestore(>lock, flags);
-- 
2.7.4

RE: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries

[Wangkai (Kevin,C)]

> -Original Message-
> From: Waiman Long [mailto:long...@redhat.com]
> Sent: Wednesday, August 16, 2017 9:29 PM
> To: Wangkai (Kevin,C); Alexander Viro; Jonathan Corbet
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linux-fsde...@vger.kernel.org; Paul E. McKenney; Andrew Morton; Ingo Molnar;
> Miklos Szeredi; Matthew Wilcox; Larry Woodman; James Bottomley
> Subject: Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries
> 
> On 08/16/2017 06:33 AM, Wangkai (Kevin,C) wrote:
> >> -Original Message-
> >> From: linux-fsdevel-ow...@vger.kernel.org
> >> [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of Waiman Long
> >> Sent: Wednesday, August 16, 2017 1:15 AM
> >> To: Alexander Viro; Jonathan Corbet
> >> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> >> linux-fsde...@vger.kernel.org; Paul E. McKenney; Andrew Morton; Ingo
> >> Molnar; Miklos Szeredi; Matthew Wilcox; Larry Woodman; James
> >> Bottomley
> >> Subject: Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries
> >>
> >> On 07/28/2017 02:34 PM, Waiman Long wrote:
> >>>  v2->v3:
> >>>   - Add a faster pruning rate when the free pool is closed to depletion.
> >>>   - As suggested by James Bottomley, add an artificial delay waiting
> >>> loop before killing a negative dentry and properly clear the
> >>> DCACHE_KILL_NEGATIVE flag if killing doesn't happen.
> >>>   - Add a new patch to track number of negative dentries that are
> >>> forcifully killed.
> >>>
> >>>  v1->v2:
> >>>   - Move the new nr_negative field to the end of dentry_stat_t structure
> >>> as suggested by Matthew Wilcox.
> >>>   - With the help of Miklos Szeredi, fix incorrect locking order in
> >>> dentry_kill() by using lock_parent() instead of locking the parent's
> >>> d_lock directly.
> >>>   - Correctly account for positive to negative dentry transitions.
> >>>   - Automatic pruning of negative dentries will now ignore the reference
> >>> bit in negative dentries but not the regular shrinking.
> >>>
> >>> A rogue application can potentially create a large number of
> >>> negative dentries in the system consuming most of the memory
> >>> available. This can impact performance of other applications running on 
> >>> the
> system.
> >>>
> >>> This patchset introduces changes to the dcache subsystem to limit
> >>> the number of negative dentries allowed to be created thus limiting
> >>> the amount of memory that can be consumed by negative dentries.
> >>>
> >>> Patch 1 tracks the number of negative dentries used and disallow the
> >>> creation of more when the limit is reached.
> >>>
> >>> Patch 2 enables /proc/sys/fs/dentry-state to report the number of
> >>> negative dentries in the system.
> >>>
> >>> Patch 3 enables automatic pruning of negative dentries when it is
> >>> close to the limit so that we won't end up killing recently used
> >>> negative dentries.
> >>>
> >>> Patch 4 prevents racing between negative dentry pruning and umount
> >>> operation.
> >>>
> >>> Patch 5 shows the number of forced negative dentry killings in
> >>> /proc/sys/fs/dentry-state. End users can then tune the
> >>> neg_dentry_pc= kernel boot parameter if they want to reduce forced
> >>> negative dentry killings.
> >>>
> >>> Waiman Long (5):
> >>>   fs/dcache: Limit numbers of negative dentries
> >>>   fs/dcache: Report negative dentry number in dentry-state
> >>>   fs/dcache: Enable automatic pruning of negative dentries
> >>>   fs/dcache: Protect negative dentry pruning from racing with umount
> >>>   fs/dcache: Track count of negative dentries forcibly killed
> >>>
> >>>  Documentation/admin-guide/kernel-parameters.txt |   7 +
> >>>  fs/dcache.c | 451
> >> ++--
> >>>  include/linux/dcache.h  |   8 +-
> >>>  include/linux/list_lru.h|   1 +
> >>>  mm/list_lru.c   |   4 +-
> >>>  5 files changed, 435 insertions(+), 36 deletions(-)
> >>>
> >> I haven't received any comment on this v3 patch for over 2 weeks. Is
> >> there anything I can do to make it more ready to be merged?
> >>
> >> Thanks,
> >> Longman
> > Hi Longman,
> > I am a fresher of fsdevel, about 2 weeks before, I have joined this
> > mail list, recently I have met the same problem of negative dentries,
> > in my opinion, the dentries should be remove together with the files or
> directories, I don't know you have submit this patch, I have another patch
> about this:
> >
> > http://marc.info/?l=linux-fsdevel=150209902215266=2
> >
> > maybe this is a foo idea...
> >
> > regards
> > Kevin
> 
> If you look at the code, the front dentries of the LRU list are removed when
> there are too many negative dentries. That includes positive dentries as well 
> as
> it is not practical to just remove the negative dentries.
> 
> I have looked at your patch. The dentry of a removed file becomes a negative
> dentry. The kernel can keep 

RE: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries

[Wangkai (Kevin,C)]

> -Original Message-
> From: Waiman Long [mailto:long...@redhat.com]
> Sent: Wednesday, August 16, 2017 9:29 PM
> To: Wangkai (Kevin,C); Alexander Viro; Jonathan Corbet
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> linux-fsde...@vger.kernel.org; Paul E. McKenney; Andrew Morton; Ingo Molnar;
> Miklos Szeredi; Matthew Wilcox; Larry Woodman; James Bottomley
> Subject: Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries
> 
> On 08/16/2017 06:33 AM, Wangkai (Kevin,C) wrote:
> >> -Original Message-
> >> From: linux-fsdevel-ow...@vger.kernel.org
> >> [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of Waiman Long
> >> Sent: Wednesday, August 16, 2017 1:15 AM
> >> To: Alexander Viro; Jonathan Corbet
> >> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> >> linux-fsde...@vger.kernel.org; Paul E. McKenney; Andrew Morton; Ingo
> >> Molnar; Miklos Szeredi; Matthew Wilcox; Larry Woodman; James
> >> Bottomley
> >> Subject: Re: [PATCH v3 0/5] fs/dcache: Limit # of negative dentries
> >>
> >> On 07/28/2017 02:34 PM, Waiman Long wrote:
> >>>  v2->v3:
> >>>   - Add a faster pruning rate when the free pool is closed to depletion.
> >>>   - As suggested by James Bottomley, add an artificial delay waiting
> >>> loop before killing a negative dentry and properly clear the
> >>> DCACHE_KILL_NEGATIVE flag if killing doesn't happen.
> >>>   - Add a new patch to track number of negative dentries that are
> >>> forcifully killed.
> >>>
> >>>  v1->v2:
> >>>   - Move the new nr_negative field to the end of dentry_stat_t structure
> >>> as suggested by Matthew Wilcox.
> >>>   - With the help of Miklos Szeredi, fix incorrect locking order in
> >>> dentry_kill() by using lock_parent() instead of locking the parent's
> >>> d_lock directly.
> >>>   - Correctly account for positive to negative dentry transitions.
> >>>   - Automatic pruning of negative dentries will now ignore the reference
> >>> bit in negative dentries but not the regular shrinking.
> >>>
> >>> A rogue application can potentially create a large number of
> >>> negative dentries in the system consuming most of the memory
> >>> available. This can impact performance of other applications running on 
> >>> the
> system.
> >>>
> >>> This patchset introduces changes to the dcache subsystem to limit
> >>> the number of negative dentries allowed to be created thus limiting
> >>> the amount of memory that can be consumed by negative dentries.
> >>>
> >>> Patch 1 tracks the number of negative dentries used and disallow the
> >>> creation of more when the limit is reached.
> >>>
> >>> Patch 2 enables /proc/sys/fs/dentry-state to report the number of
> >>> negative dentries in the system.
> >>>
> >>> Patch 3 enables automatic pruning of negative dentries when it is
> >>> close to the limit so that we won't end up killing recently used
> >>> negative dentries.
> >>>
> >>> Patch 4 prevents racing between negative dentry pruning and umount
> >>> operation.
> >>>
> >>> Patch 5 shows the number of forced negative dentry killings in
> >>> /proc/sys/fs/dentry-state. End users can then tune the
> >>> neg_dentry_pc= kernel boot parameter if they want to reduce forced
> >>> negative dentry killings.
> >>>
> >>> Waiman Long (5):
> >>>   fs/dcache: Limit numbers of negative dentries
> >>>   fs/dcache: Report negative dentry number in dentry-state
> >>>   fs/dcache: Enable automatic pruning of negative dentries
> >>>   fs/dcache: Protect negative dentry pruning from racing with umount
> >>>   fs/dcache: Track count of negative dentries forcibly killed
> >>>
> >>>  Documentation/admin-guide/kernel-parameters.txt |   7 +
> >>>  fs/dcache.c | 451
> >> ++--
> >>>  include/linux/dcache.h  |   8 +-
> >>>  include/linux/list_lru.h|   1 +
> >>>  mm/list_lru.c   |   4 +-
> >>>  5 files changed, 435 insertions(+), 36 deletions(-)
> >>>
> >> I haven't received any comment on this v3 patch for over 2 weeks. Is
> >> there anything I can do to make it more ready to be merged?
> >>
> >> Thanks,
> >> Longman
> > Hi Longman,
> > I am a fresher of fsdevel, about 2 weeks before, I have joined this
> > mail list, recently I have met the same problem of negative dentries,
> > in my opinion, the dentries should be remove together with the files or
> directories, I don't know you have submit this patch, I have another patch
> about this:
> >
> > http://marc.info/?l=linux-fsdevel=150209902215266=2
> >
> > maybe this is a foo idea...
> >
> > regards
> > Kevin
> 
> If you look at the code, the front dentries of the LRU list are removed when
> there are too many negative dentries. That includes positive dentries as well 
> as
> it is not practical to just remove the negative dentries.
> 
> I have looked at your patch. The dentry of a removed file becomes a negative
> dentry. The kernel can keep 

Re: [PATCH v4 1/6] Documentation: perf: hisi: Documentation for HiSilicon SoC PMU driver

[Jonathan Cameron]

On Thu, 17 Aug 2017 10:30:23 +0800
Zhangshaokun  wrote:

> Hi Mark,
> 
> Thanks for your comments.
> 
> On 2017/8/15 17:50, Mark Rutland wrote:
> > Hi,
> > 
> > On Tue, Jul 25, 2017 at 08:10:37PM +0800, Shaokun Zhang wrote:  
> >> This patch adds documentation for the uncore PMUs on HiSilicon SoC.
> >>
> >> Reviewed-by: Jonathan Cameron 
> >> Signed-off-by: Shaokun Zhang 
> >> Signed-off-by: Anurup M 
> >> ---
> >>  Documentation/perf/hisi-pmu.txt | 52 
> >> +
> >>  1 file changed, 52 insertions(+)
> >>  create mode 100644 Documentation/perf/hisi-pmu.txt
> >>
> >> diff --git a/Documentation/perf/hisi-pmu.txt 
> >> b/Documentation/perf/hisi-pmu.txt
> >> new file mode 100644
> >> index 000..f45a03d
> >> --- /dev/null
> >> +++ b/Documentation/perf/hisi-pmu.txt
> >> @@ -0,0 +1,52 @@
> >> +HiSilicon SoC uncore Performance Monitoring Unit (PMU)
> >> +==
> >> +The HiSilicon SoC chip comprehends various independent system device PMUs 
> >>  
> > 
> > Nit: s/comprehends/comprises/ would be easier to read.
> >   
> 
> Ok.

s/comprises/includes/ would perhaps be even better.  There are a few other
things in the SoC beyond independent system device PMUs :)

(good spot though - I completely missed comprehends when doing the internal
review!)

> 
> >> +such as L3 cache (L3C), Hydra Home Agent (HHA) and DDRC. These PMUs are
> >> +independent and have hardware logic to gather statistics and performance
> >> +information.
> >> +
> >> +HiSilicon SoC encapsulates multiple CPU and IO dies. Each CPU cluster  
> > 
> > Nit: The Hisilicon SoC
> >   
> 
> Ok.

I disagree. It is odd but the company name is HiSilicon with the capital S.

> 
> >> +(CCL) is made up of 4 cpu cores sharing one L3 cache; Each CPU die is  
> > 
> > Nit: s/Each/each/
> >   
> 
> Ok.
> 
> >> +called Super CPU cluster (SCCL) and is made up of 6 CCLs. Each SCCL has
> >> +two HHAs (0 - 1) and four DDRCs (0 - 3), respectively.
> >> +
> >> +HiSilicon SoC uncore PMU driver
> >> +---
> >> +Each device PMU has separate registers for event counting, control and
> >> +interrupt, and the PMU driver shall register perf PMU drivers like L3C,
> >> +HHA and DDRC etc. The available events and configuration options shall
> >> +be described in the sysfs, see /sys/devices/hisi_*   
> > 
> > What exactly its exposed under /sys/devices/hisi_* ?
> >   
> 
> Apologies that i shall list 
> /sys/devices/hisi_sccl{X}_/ and
> will change it in next version.
> 
> >> or /sys/bus/
> >> +event_source/devices/hisi_*.  
> > 
> > Please don't wrap paths; keep this on one line.
> >   
> 
> Ok.
> 
> >> +The "perf list" command shall list the available events from sysfs.
> >> +
> >> +Each L3C, HHA and DDRC in one SCCL are registered as an separate PMU with 
> >> perf.
> >> +The PMU name will appear in event listing as hisi_module 
> >> _.
> >> +where "index-id" is the index of module and "sccl-id" is the identifier of
> >> +the SCCL.
> >> +e.g. hisi_l3c0_1/rd_hit_cpipe is READ_HIT_CPIPE event of L3C index #0 and 
> >> SCCL
> >> +ID #1.
> >> +e.g. hisi_hha0_1/rx_operations is RX_OPERATIONS event of HHA index #0 and 
> >> SCCL
> >> +ID #1.  
> > 
> > It would make more sense for this to be hierarichal, e.g. 
> > hisi_sccl{X}_l3c{Y}.
> >   
> 
> Surely, it is nicer.
> 
> Thanks.
> Shaokun
> 
> > Other than the above nits, this documentation is very useful. Thanks for
> > putting this together.
> > 
> > Thanks,
> > Mark.
> > ___
> > linuxarm mailing list
> > linux...@huawei.com
> > http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
> > 
> > .
> >   
> 
> ___
> linuxarm mailing list
> linux...@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

Re: [PATCH v4 1/6] Documentation: perf: hisi: Documentation for HiSilicon SoC PMU driver

[Jonathan Cameron]

On Thu, 17 Aug 2017 10:30:23 +0800
Zhangshaokun  wrote:

> Hi Mark,
> 
> Thanks for your comments.
> 
> On 2017/8/15 17:50, Mark Rutland wrote:
> > Hi,
> > 
> > On Tue, Jul 25, 2017 at 08:10:37PM +0800, Shaokun Zhang wrote:  
> >> This patch adds documentation for the uncore PMUs on HiSilicon SoC.
> >>
> >> Reviewed-by: Jonathan Cameron 
> >> Signed-off-by: Shaokun Zhang 
> >> Signed-off-by: Anurup M 
> >> ---
> >>  Documentation/perf/hisi-pmu.txt | 52 
> >> +
> >>  1 file changed, 52 insertions(+)
> >>  create mode 100644 Documentation/perf/hisi-pmu.txt
> >>
> >> diff --git a/Documentation/perf/hisi-pmu.txt 
> >> b/Documentation/perf/hisi-pmu.txt
> >> new file mode 100644
> >> index 000..f45a03d
> >> --- /dev/null
> >> +++ b/Documentation/perf/hisi-pmu.txt
> >> @@ -0,0 +1,52 @@
> >> +HiSilicon SoC uncore Performance Monitoring Unit (PMU)
> >> +==
> >> +The HiSilicon SoC chip comprehends various independent system device PMUs 
> >>  
> > 
> > Nit: s/comprehends/comprises/ would be easier to read.
> >   
> 
> Ok.

s/comprises/includes/ would perhaps be even better.  There are a few other
things in the SoC beyond independent system device PMUs :)

(good spot though - I completely missed comprehends when doing the internal
review!)

> 
> >> +such as L3 cache (L3C), Hydra Home Agent (HHA) and DDRC. These PMUs are
> >> +independent and have hardware logic to gather statistics and performance
> >> +information.
> >> +
> >> +HiSilicon SoC encapsulates multiple CPU and IO dies. Each CPU cluster  
> > 
> > Nit: The Hisilicon SoC
> >   
> 
> Ok.

I disagree. It is odd but the company name is HiSilicon with the capital S.

> 
> >> +(CCL) is made up of 4 cpu cores sharing one L3 cache; Each CPU die is  
> > 
> > Nit: s/Each/each/
> >   
> 
> Ok.
> 
> >> +called Super CPU cluster (SCCL) and is made up of 6 CCLs. Each SCCL has
> >> +two HHAs (0 - 1) and four DDRCs (0 - 3), respectively.
> >> +
> >> +HiSilicon SoC uncore PMU driver
> >> +---
> >> +Each device PMU has separate registers for event counting, control and
> >> +interrupt, and the PMU driver shall register perf PMU drivers like L3C,
> >> +HHA and DDRC etc. The available events and configuration options shall
> >> +be described in the sysfs, see /sys/devices/hisi_*   
> > 
> > What exactly its exposed under /sys/devices/hisi_* ?
> >   
> 
> Apologies that i shall list 
> /sys/devices/hisi_sccl{X}_/ and
> will change it in next version.
> 
> >> or /sys/bus/
> >> +event_source/devices/hisi_*.  
> > 
> > Please don't wrap paths; keep this on one line.
> >   
> 
> Ok.
> 
> >> +The "perf list" command shall list the available events from sysfs.
> >> +
> >> +Each L3C, HHA and DDRC in one SCCL are registered as an separate PMU with 
> >> perf.
> >> +The PMU name will appear in event listing as hisi_module 
> >> _.
> >> +where "index-id" is the index of module and "sccl-id" is the identifier of
> >> +the SCCL.
> >> +e.g. hisi_l3c0_1/rd_hit_cpipe is READ_HIT_CPIPE event of L3C index #0 and 
> >> SCCL
> >> +ID #1.
> >> +e.g. hisi_hha0_1/rx_operations is RX_OPERATIONS event of HHA index #0 and 
> >> SCCL
> >> +ID #1.  
> > 
> > It would make more sense for this to be hierarichal, e.g. 
> > hisi_sccl{X}_l3c{Y}.
> >   
> 
> Surely, it is nicer.
> 
> Thanks.
> Shaokun
> 
> > Other than the above nits, this documentation is very useful. Thanks for
> > putting this together.
> > 
> > Thanks,
> > Mark.
> > ___
> > linuxarm mailing list
> > linux...@huawei.com
> > http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
> > 
> > .
> >   
> 
> ___
> linuxarm mailing list
> linux...@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

Re: [RFC][PATCH 2/2] selftests: timers: freq-step: Fix build warning

[Shuah Khan]

On 08/16/2017 09:31 PM, John Stultz wrote:
> On Wed, Aug 16, 2017 at 4:10 PM, John Stultz  wrote:
>> On Wed, Aug 16, 2017 at 4:01 PM, Shuah Khan  wrote:
>>> Hi John,
>>>
>>> On 08/15/2017 06:11 AM, Miroslav Lichvar wrote:
 On Mon, Aug 14, 2017 at 02:01:36PM -0700, John Stultz wrote:
> Fixes the following build warning:
> freq-step.c: In function ‘main’:
> freq-step.c:271:1: warning: control reaches end of non-void function 
> [-Wreturn-type]

> @@ -268,4 +268,6 @@ int main(int argc, char **argv)
>  ksft_exit_fail();
>>>
>>> This needs to be changes as well to return ksft_exit_fail();
>
>  ksft_exit_pass();
> +
> +return 0;
>  }

 It seems most tests use "return ksft_exit_pass();". Would that be
 preferred over separate return? I don't have a preference.
>>>
>>> Let's go with "return ksft_exit_pass();"
>>
>> Thanks for the review, I've made both changes and I'll send these out
>> shortly with the rest of my 4.14 focused queue.
> 
> Shuah,
>   One more question here. I'm noticing that running "make
> run_destructive_tests" in the timers dir, the freq-step test returns
> ksft_exit_skip, which results in the test returning an exit code of 4,
> which causes make to think it failed, halting the testing.

I think exit code 4 might not be good option. It could be tripping the
make target rules.

> 
> I'm guessing there is some extra logic for how to properly run
> extended tests such that the various error codes are handled and a
> skip doesn't result in the test stopping?
> 
> Any suggestions/pointers?
> 

Skip is really a case of not being able to run the test and it might not
be necessary to differentiate SKIP vs. PASS. I think we can just get rid 
of EXIT_SKIP and use EXIT_PASS. I would rather do that than adding handling
for exit code 4.

I can get that change in for 4.14-rc1 if this can wait or I will try to get
that into 4.13-rc7 possibly.

Also just FYI - I am going to send out patch series for timers test conversion
to TAP13 tomorrow.

thanks,
-- Shuah

Re: [RFC][PATCH 2/2] selftests: timers: freq-step: Fix build warning

[Shuah Khan]

On 08/16/2017 09:31 PM, John Stultz wrote:
> On Wed, Aug 16, 2017 at 4:10 PM, John Stultz  wrote:
>> On Wed, Aug 16, 2017 at 4:01 PM, Shuah Khan  wrote:
>>> Hi John,
>>>
>>> On 08/15/2017 06:11 AM, Miroslav Lichvar wrote:
 On Mon, Aug 14, 2017 at 02:01:36PM -0700, John Stultz wrote:
> Fixes the following build warning:
> freq-step.c: In function ‘main’:
> freq-step.c:271:1: warning: control reaches end of non-void function 
> [-Wreturn-type]

> @@ -268,4 +268,6 @@ int main(int argc, char **argv)
>  ksft_exit_fail();
>>>
>>> This needs to be changes as well to return ksft_exit_fail();
>
>  ksft_exit_pass();
> +
> +return 0;
>  }

 It seems most tests use "return ksft_exit_pass();". Would that be
 preferred over separate return? I don't have a preference.
>>>
>>> Let's go with "return ksft_exit_pass();"
>>
>> Thanks for the review, I've made both changes and I'll send these out
>> shortly with the rest of my 4.14 focused queue.
> 
> Shuah,
>   One more question here. I'm noticing that running "make
> run_destructive_tests" in the timers dir, the freq-step test returns
> ksft_exit_skip, which results in the test returning an exit code of 4,
> which causes make to think it failed, halting the testing.

I think exit code 4 might not be good option. It could be tripping the
make target rules.

> 
> I'm guessing there is some extra logic for how to properly run
> extended tests such that the various error codes are handled and a
> skip doesn't result in the test stopping?
> 
> Any suggestions/pointers?
> 

Skip is really a case of not being able to run the test and it might not
be necessary to differentiate SKIP vs. PASS. I think we can just get rid 
of EXIT_SKIP and use EXIT_PASS. I would rather do that than adding handling
for exit code 4.

I can get that change in for 4.14-rc1 if this can wait or I will try to get
that into 4.13-rc7 possibly.

Also just FYI - I am going to send out patch series for timers test conversion
to TAP13 tomorrow.

thanks,
-- Shuah

Re: [PATCH 2/2 v6] printk: Add monotonic, boottime, and realtime timestamps

[John Stultz]

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 98fe715522e8..c303b235a0b1 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1,19 +1,61 @@
>  menu "printk and dmesg options"
>
> +choice
> +   prompt "printk default clock timestamp"
> +
> +config PRINTK_TIME_DISABLE
> +   bool "Disabled"
> +   help
> +Selecting this option disables the time stamps of printk().
> +
> +config PRINTK_TIME_LOCAL
> +   bool "Local Clock"
> +   help
> + Selecting this option causes the time stamps of printk() to be
> + stamped with the unadjusted hardware clock.
> +
> +config PRINTK_TIME_BOOT
> +   bool "CLOCK_BOOTTIME"
> +   help
> + Selecting this option causes the time stamps of printk() to be
> + stamped with the adjusted boottime clock.
> +
> +config PRINTK_TIME_MONO
> +   bool "CLOCK_MONOTONIC"
> +   help
> + Selecting this option causes the time stamps of printk() to be
> + stamped with the adjusted monotonic clock.
> +
> +config PRINTK_TIME_REAL
> +   bool "CLOCK_REALTIME"
> +   help
> + Selecting this option causes the time stamps of printk() to be
> + stamped with the adjusted realtime clock.
> +
> +endchoice
> +
>  config PRINTK_TIME
> -   bool "Show timing information on printks"
> +   int "Show timestamp information on printks"

You need to drop the prompt on this, as it ends up with this insane
setup where you chose from the choice list, but then you can go and
set the PRINTK_TIME manually to something else?

So PRINTK_TIME_REAL can be y, but PRINTK_TIME can be 2...  Yuck.

I'm still annoyed enough with this Kconfig/defconfig noise in the
patch that I'm going to take my own shot at it ( hopefully there's a
better way, but likely it will help me understand why it was done this
way :).

thanks
-john

Re: [PATCH 2/2 v6] printk: Add monotonic, boottime, and realtime timestamps

[John Stultz]

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 98fe715522e8..c303b235a0b1 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1,19 +1,61 @@
>  menu "printk and dmesg options"
>
> +choice
> +   prompt "printk default clock timestamp"
> +
> +config PRINTK_TIME_DISABLE
> +   bool "Disabled"
> +   help
> +Selecting this option disables the time stamps of printk().
> +
> +config PRINTK_TIME_LOCAL
> +   bool "Local Clock"
> +   help
> + Selecting this option causes the time stamps of printk() to be
> + stamped with the unadjusted hardware clock.
> +
> +config PRINTK_TIME_BOOT
> +   bool "CLOCK_BOOTTIME"
> +   help
> + Selecting this option causes the time stamps of printk() to be
> + stamped with the adjusted boottime clock.
> +
> +config PRINTK_TIME_MONO
> +   bool "CLOCK_MONOTONIC"
> +   help
> + Selecting this option causes the time stamps of printk() to be
> + stamped with the adjusted monotonic clock.
> +
> +config PRINTK_TIME_REAL
> +   bool "CLOCK_REALTIME"
> +   help
> + Selecting this option causes the time stamps of printk() to be
> + stamped with the adjusted realtime clock.
> +
> +endchoice
> +
>  config PRINTK_TIME
> -   bool "Show timing information on printks"
> +   int "Show timestamp information on printks"

You need to drop the prompt on this, as it ends up with this insane
setup where you chose from the choice list, but then you can go and
set the PRINTK_TIME manually to something else?

So PRINTK_TIME_REAL can be y, but PRINTK_TIME can be 2...  Yuck.

I'm still annoyed enough with this Kconfig/defconfig noise in the
patch that I'm going to take my own shot at it ( hopefully there's a
better way, but likely it will help me understand why it was done this
way :).

thanks
-john

Re: [PATCH v4] vfio: platform: reset: Add Broadcom FlexRM reset module

[Anup Patel]

On Fri, Aug 11, 2017 at 12:53 AM, Alex Williamson
 wrote:
> On Wed,  2 Aug 2017 11:08:30 +0530
> Anup Patel  wrote:
>
>> This patch adds Broadcom FlexRM low-level reset for
>> VFIO platform.
>>
>> It will do the following:
>> 1. Disable/Deactivate each FlexRM ring
>> 2. Flush each FlexRM ring
>>
>> The cleanup sequence for FlexRM rings is adapted from
>> Broadcom FlexRM mailbox driver.
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Oza Oza 
>> Reviewed-by: Scott Branden 
>> Reviewed-by: Eric Auger 
>> ---
>>  drivers/vfio/platform/reset/Kconfig|   8 ++
>>  drivers/vfio/platform/reset/Makefile   |   1 +
>>  .../vfio/platform/reset/vfio_platform_bcmflexrm.c  | 100 
>> +
>>  3 files changed, 109 insertions(+)
>>  create mode 100644 drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>>
>> diff --git a/drivers/vfio/platform/reset/Kconfig 
>> b/drivers/vfio/platform/reset/Kconfig
>> index 705..8833805 100644
>> --- a/drivers/vfio/platform/reset/Kconfig
>> +++ b/drivers/vfio/platform/reset/Kconfig
>> @@ -13,3 +13,11 @@ config VFIO_PLATFORM_AMDXGBE_RESET
>> Enables the VFIO platform driver to handle reset for AMD XGBE
>>
>> If you don't know what to do here, say N.
>> +
>> +config VFIO_PLATFORM_BCMFLEXRM_RESET
>> + tristate "VFIO support for Broadcom FlexRM reset"
>> + depends on VFIO_PLATFORM && (ARCH_BCM_IPROC || COMPILE_TEST)
>> + help
>> +   Enables the VFIO platform driver to handle reset for Broadcom FlexRM
>> +
>> +   If you don't know what to do here, say N.
>> diff --git a/drivers/vfio/platform/reset/Makefile 
>> b/drivers/vfio/platform/reset/Makefile
>> index 93f4e23..8d9874b 100644
>> --- a/drivers/vfio/platform/reset/Makefile
>> +++ b/drivers/vfio/platform/reset/Makefile
>> @@ -5,3 +5,4 @@ ccflags-y += -Idrivers/vfio/platform
>>
>>  obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += 
>> vfio-platform-calxedaxgmac.o
>>  obj-$(CONFIG_VFIO_PLATFORM_AMDXGBE_RESET) += vfio-platform-amdxgbe.o
>> +obj-$(CONFIG_VFIO_PLATFORM_BCMFLEXRM_RESET) += vfio_platform_bcmflexrm.o
>> diff --git a/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c 
>> b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>> new file mode 100644
>> index 000..104c3c1
>> --- /dev/null
>> +++ b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>> @@ -0,0 +1,100 @@
>> +/*
>> + * Copyright (C) 2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + */
>> +
>> +/*
>> + * This driver provides reset support for Broadcom FlexRM ring manager
>> + * to VFIO platform.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "vfio_platform_private.h"
>> +
>> +/* FlexRM configuration */
>> +#define RING_REGS_SIZE   0x1
>> +#define RING_VER_MAGIC   0x76303031
>> +
>> +/* Per-Ring register offsets */
>> +#define RING_VER 0x000
>> +#define RING_CONTROL 0x034
>> +#define RING_FLUSH_DONE  0x038
>> +
>> +/* Register RING_CONTROL fields */
>> +#define CONTROL_FLUSH_SHIFT  5
>> +
>> +/* Register RING_FLUSH_DONE fields */
>> +#define FLUSH_DONE_MASK  0x1
>> +
>> +static int vfio_platform_bcmflexrm_shutdown(void __iomem *ring)
>> +{
>> + unsigned int timeout;
>> +
>> + /* Disable/inactivate ring */
>> + writel_relaxed(0x0, ring + RING_CONTROL);
>> +
>> + /* Flush ring with timeout of 1s */
>> + timeout = 1000;
>> + writel_relaxed(BIT(CONTROL_FLUSH_SHIFT), ring + RING_CONTROL);
>> + do {
>> + if (readl_relaxed(ring + RING_FLUSH_DONE) & FLUSH_DONE_MASK)
>> + break;
>> + mdelay(1);
>> + } while (timeout--);
>> +
>> + if (!timeout) {
>> + pr_warn("VFIO FlexRM shutdown timeout\n");
>> + return -ETIMEDOUT;
>> + }
>
>
> This doesn't work, timeout is ~0 here.

Sure, I will use "--timeout" instead of "timeout--" which will
fix the issue.

Thanks for pointing.

Regards,
Anup

Re: [PATCH v4] vfio: platform: reset: Add Broadcom FlexRM reset module

[Anup Patel]

On Fri, Aug 11, 2017 at 12:53 AM, Alex Williamson
 wrote:
> On Wed,  2 Aug 2017 11:08:30 +0530
> Anup Patel  wrote:
>
>> This patch adds Broadcom FlexRM low-level reset for
>> VFIO platform.
>>
>> It will do the following:
>> 1. Disable/Deactivate each FlexRM ring
>> 2. Flush each FlexRM ring
>>
>> The cleanup sequence for FlexRM rings is adapted from
>> Broadcom FlexRM mailbox driver.
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Oza Oza 
>> Reviewed-by: Scott Branden 
>> Reviewed-by: Eric Auger 
>> ---
>>  drivers/vfio/platform/reset/Kconfig|   8 ++
>>  drivers/vfio/platform/reset/Makefile   |   1 +
>>  .../vfio/platform/reset/vfio_platform_bcmflexrm.c  | 100 
>> +
>>  3 files changed, 109 insertions(+)
>>  create mode 100644 drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>>
>> diff --git a/drivers/vfio/platform/reset/Kconfig 
>> b/drivers/vfio/platform/reset/Kconfig
>> index 705..8833805 100644
>> --- a/drivers/vfio/platform/reset/Kconfig
>> +++ b/drivers/vfio/platform/reset/Kconfig
>> @@ -13,3 +13,11 @@ config VFIO_PLATFORM_AMDXGBE_RESET
>> Enables the VFIO platform driver to handle reset for AMD XGBE
>>
>> If you don't know what to do here, say N.
>> +
>> +config VFIO_PLATFORM_BCMFLEXRM_RESET
>> + tristate "VFIO support for Broadcom FlexRM reset"
>> + depends on VFIO_PLATFORM && (ARCH_BCM_IPROC || COMPILE_TEST)
>> + help
>> +   Enables the VFIO platform driver to handle reset for Broadcom FlexRM
>> +
>> +   If you don't know what to do here, say N.
>> diff --git a/drivers/vfio/platform/reset/Makefile 
>> b/drivers/vfio/platform/reset/Makefile
>> index 93f4e23..8d9874b 100644
>> --- a/drivers/vfio/platform/reset/Makefile
>> +++ b/drivers/vfio/platform/reset/Makefile
>> @@ -5,3 +5,4 @@ ccflags-y += -Idrivers/vfio/platform
>>
>>  obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += 
>> vfio-platform-calxedaxgmac.o
>>  obj-$(CONFIG_VFIO_PLATFORM_AMDXGBE_RESET) += vfio-platform-amdxgbe.o
>> +obj-$(CONFIG_VFIO_PLATFORM_BCMFLEXRM_RESET) += vfio_platform_bcmflexrm.o
>> diff --git a/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c 
>> b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>> new file mode 100644
>> index 000..104c3c1
>> --- /dev/null
>> +++ b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
>> @@ -0,0 +1,100 @@
>> +/*
>> + * Copyright (C) 2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + */
>> +
>> +/*
>> + * This driver provides reset support for Broadcom FlexRM ring manager
>> + * to VFIO platform.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "vfio_platform_private.h"
>> +
>> +/* FlexRM configuration */
>> +#define RING_REGS_SIZE   0x1
>> +#define RING_VER_MAGIC   0x76303031
>> +
>> +/* Per-Ring register offsets */
>> +#define RING_VER 0x000
>> +#define RING_CONTROL 0x034
>> +#define RING_FLUSH_DONE  0x038
>> +
>> +/* Register RING_CONTROL fields */
>> +#define CONTROL_FLUSH_SHIFT  5
>> +
>> +/* Register RING_FLUSH_DONE fields */
>> +#define FLUSH_DONE_MASK  0x1
>> +
>> +static int vfio_platform_bcmflexrm_shutdown(void __iomem *ring)
>> +{
>> + unsigned int timeout;
>> +
>> + /* Disable/inactivate ring */
>> + writel_relaxed(0x0, ring + RING_CONTROL);
>> +
>> + /* Flush ring with timeout of 1s */
>> + timeout = 1000;
>> + writel_relaxed(BIT(CONTROL_FLUSH_SHIFT), ring + RING_CONTROL);
>> + do {
>> + if (readl_relaxed(ring + RING_FLUSH_DONE) & FLUSH_DONE_MASK)
>> + break;
>> + mdelay(1);
>> + } while (timeout--);
>> +
>> + if (!timeout) {
>> + pr_warn("VFIO FlexRM shutdown timeout\n");
>> + return -ETIMEDOUT;
>> + }
>
>
> This doesn't work, timeout is ~0 here.

Sure, I will use "--timeout" instead of "timeout--" which will
fix the issue.

Thanks for pointing.

Regards,
Anup

Re: [PATCH v6 3/5] drm/vc4: Set up the DSI host at pdev probe time, not component bind.

[Archit Taneja]

On 08/16/2017 05:17 AM, Eric Anholt wrote:

We need the following things to happen in sequence:

DSI host creation
DSI device creation in the panel driver (needs DSI host)
DSI device attach from panel to host.
DSI drm_panel_add()
DSI encoder creation
DSI encoder's DRM panel/bridge attach

Unless we allow device creation while the host isn't up yet, we need
to break the -EPROBE_DEFER deadlock between the panel driver looking
up the host and the host driver looking up the panel.  We can do so by
moving the DSI host creation outside of the component bind loop, and
the panel/bridge lookup/attach into the component bind process.


Reviewed-by: Archit Taneja 



Signed-off-by: Eric Anholt 
---
  drivers/gpu/drm/vc4/vc4_dsi.c | 97 +--
  1 file changed, 57 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 2516cd3a1d87..ec1d646b3151 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -33,6 +33,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -504,7 +505,6 @@ struct vc4_dsi {
struct mipi_dsi_host dsi_host;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
-   bool is_panel_bridge;
  
  	void __iomem *regs;
  
@@ -1289,7 +1289,6 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,

   struct mipi_dsi_device *device)
  {
struct vc4_dsi *dsi = host_to_dsi(host);
-   int ret = 0;
  
  	dsi->lanes = device->lanes;

dsi->channel = device->channel;
@@ -1324,34 +1323,12 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host 
*host,
return 0;
}
  
-	dsi->bridge = of_drm_find_bridge(device->dev.of_node);

-   if (!dsi->bridge) {
-   struct drm_panel *panel =
-   of_drm_find_panel(device->dev.of_node);
-
-   dsi->bridge = drm_panel_bridge_add(panel,
-  DRM_MODE_CONNECTOR_DSI);
-   if (IS_ERR(dsi->bridge)) {
-   ret = PTR_ERR(dsi->bridge);
-   dsi->bridge = NULL;
-   return ret;
-   }
-   dsi->is_panel_bridge = true;
-   }
-
-   return drm_bridge_attach(dsi->encoder, dsi->bridge, NULL);
+   return 0;
  }
  
  static int vc4_dsi_host_detach(struct mipi_dsi_host *host,

   struct mipi_dsi_device *device)
  {
-   struct vc4_dsi *dsi = host_to_dsi(host);
-
-   if (dsi->is_panel_bridge) {
-   drm_panel_bridge_remove(dsi->bridge);
-   dsi->bridge = NULL;
-   }
-
return 0;
  }
  
@@ -1493,16 +1470,13 @@ static int vc4_dsi_bind(struct device *dev, struct device *master, void *data)

struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = dev_get_drvdata(master);
struct vc4_dev *vc4 = to_vc4_dev(drm);
-   struct vc4_dsi *dsi;
+   struct vc4_dsi *dsi = dev_get_drvdata(dev);
struct vc4_dsi_encoder *vc4_dsi_encoder;
+   struct drm_panel *panel;
const struct of_device_id *match;
dma_cap_mask_t dma_mask;
int ret;
  
-	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);

-   if (!dsi)
-   return -ENOMEM;
-
match = of_match_device(vc4_dsi_dt_match, dev);
if (!match)
return -ENODEV;
@@ -1517,7 +1491,6 @@ static int vc4_dsi_bind(struct device *dev, struct device 
*master, void *data)
vc4_dsi_encoder->dsi = dsi;
dsi->encoder = _dsi_encoder->base.base;
  
-	dsi->pdev = pdev;

dsi->regs = vc4_ioremap_regs(pdev, 0);
if (IS_ERR(dsi->regs))
return PTR_ERR(dsi->regs);
@@ -1598,6 +1571,18 @@ static int vc4_dsi_bind(struct device *dev, struct 
device *master, void *data)
return ret;
}
  
+	ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,

+ , >bridge);
+   if (ret)
+   return ret;
+
+   if (panel) {
+   dsi->bridge = devm_drm_panel_bridge_add(dev, panel,
+   DRM_MODE_CONNECTOR_DSI);
+   if (IS_ERR(dsi->bridge))
+   return PTR_ERR(dsi->bridge);
+   }
+
/* The esc clock rate is supposed to always be 100Mhz. */
ret = clk_set_rate(dsi->escape_clock, 100 * 100);
if (ret) {
@@ -1616,12 +1601,11 @@ static int vc4_dsi_bind(struct device *dev, struct 
device *master, void *data)
 DRM_MODE_ENCODER_DSI, NULL);
drm_encoder_helper_add(dsi->encoder, _dsi_encoder_helper_funcs);
  
-	dsi->dsi_host.ops = _dsi_host_ops;

-   dsi->dsi_host.dev = dev;
-
-   mipi_dsi_host_register(>dsi_host);
-
-   dev_set_drvdata(dev, dsi);
+   

Re: [PATCH v6 3/5] drm/vc4: Set up the DSI host at pdev probe time, not component bind.

[Archit Taneja]

On 08/16/2017 05:17 AM, Eric Anholt wrote:

We need the following things to happen in sequence:

DSI host creation
DSI device creation in the panel driver (needs DSI host)
DSI device attach from panel to host.
DSI drm_panel_add()
DSI encoder creation
DSI encoder's DRM panel/bridge attach

Unless we allow device creation while the host isn't up yet, we need
to break the -EPROBE_DEFER deadlock between the panel driver looking
up the host and the host driver looking up the panel.  We can do so by
moving the DSI host creation outside of the component bind loop, and
the panel/bridge lookup/attach into the component bind process.


Reviewed-by: Archit Taneja 



Signed-off-by: Eric Anholt 
---
  drivers/gpu/drm/vc4/vc4_dsi.c | 97 +--
  1 file changed, 57 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 2516cd3a1d87..ec1d646b3151 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -33,6 +33,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -504,7 +505,6 @@ struct vc4_dsi {
struct mipi_dsi_host dsi_host;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
-   bool is_panel_bridge;
  
  	void __iomem *regs;
  
@@ -1289,7 +1289,6 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,

   struct mipi_dsi_device *device)
  {
struct vc4_dsi *dsi = host_to_dsi(host);
-   int ret = 0;
  
  	dsi->lanes = device->lanes;

dsi->channel = device->channel;
@@ -1324,34 +1323,12 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host 
*host,
return 0;
}
  
-	dsi->bridge = of_drm_find_bridge(device->dev.of_node);

-   if (!dsi->bridge) {
-   struct drm_panel *panel =
-   of_drm_find_panel(device->dev.of_node);
-
-   dsi->bridge = drm_panel_bridge_add(panel,
-  DRM_MODE_CONNECTOR_DSI);
-   if (IS_ERR(dsi->bridge)) {
-   ret = PTR_ERR(dsi->bridge);
-   dsi->bridge = NULL;
-   return ret;
-   }
-   dsi->is_panel_bridge = true;
-   }
-
-   return drm_bridge_attach(dsi->encoder, dsi->bridge, NULL);
+   return 0;
  }
  
  static int vc4_dsi_host_detach(struct mipi_dsi_host *host,

   struct mipi_dsi_device *device)
  {
-   struct vc4_dsi *dsi = host_to_dsi(host);
-
-   if (dsi->is_panel_bridge) {
-   drm_panel_bridge_remove(dsi->bridge);
-   dsi->bridge = NULL;
-   }
-
return 0;
  }
  
@@ -1493,16 +1470,13 @@ static int vc4_dsi_bind(struct device *dev, struct device *master, void *data)

struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = dev_get_drvdata(master);
struct vc4_dev *vc4 = to_vc4_dev(drm);
-   struct vc4_dsi *dsi;
+   struct vc4_dsi *dsi = dev_get_drvdata(dev);
struct vc4_dsi_encoder *vc4_dsi_encoder;
+   struct drm_panel *panel;
const struct of_device_id *match;
dma_cap_mask_t dma_mask;
int ret;
  
-	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);

-   if (!dsi)
-   return -ENOMEM;
-
match = of_match_device(vc4_dsi_dt_match, dev);
if (!match)
return -ENODEV;
@@ -1517,7 +1491,6 @@ static int vc4_dsi_bind(struct device *dev, struct device 
*master, void *data)
vc4_dsi_encoder->dsi = dsi;
dsi->encoder = _dsi_encoder->base.base;
  
-	dsi->pdev = pdev;

dsi->regs = vc4_ioremap_regs(pdev, 0);
if (IS_ERR(dsi->regs))
return PTR_ERR(dsi->regs);
@@ -1598,6 +1571,18 @@ static int vc4_dsi_bind(struct device *dev, struct 
device *master, void *data)
return ret;
}
  
+	ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,

+ , >bridge);
+   if (ret)
+   return ret;
+
+   if (panel) {
+   dsi->bridge = devm_drm_panel_bridge_add(dev, panel,
+   DRM_MODE_CONNECTOR_DSI);
+   if (IS_ERR(dsi->bridge))
+   return PTR_ERR(dsi->bridge);
+   }
+
/* The esc clock rate is supposed to always be 100Mhz. */
ret = clk_set_rate(dsi->escape_clock, 100 * 100);
if (ret) {
@@ -1616,12 +1601,11 @@ static int vc4_dsi_bind(struct device *dev, struct 
device *master, void *data)
 DRM_MODE_ENCODER_DSI, NULL);
drm_encoder_helper_add(dsi->encoder, _dsi_encoder_helper_funcs);
  
-	dsi->dsi_host.ops = _dsi_host_ops;

-   dsi->dsi_host.dev = dev;
-
-   mipi_dsi_host_register(>dsi_host);
-
-   dev_set_drvdata(dev, dsi);
+   ret = drm_bridge_attach(dsi->encoder, 

Re: [PATCH v2 03/16] dmaengine: bcm-sba-raid: Common flags for sba_request state and fence

[Vinod Koul]

On Tue, Aug 01, 2017 at 04:07:47PM +0530, Anup Patel wrote:
> This patch merges sba_request state and fence into common
> sba_request flags. Also, in-future we can extend sba_request
> flags as required.

and it also changes the flag values to bits, which I have no idea why that
was done, care to explain that please...

> 
> Signed-off-by: Anup Patel 
> ---
>  drivers/dma/bcm-sba-raid.c | 66 
> ++
>  1 file changed, 38 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
> index f81d5ac..6fa3df1 100644
> --- a/drivers/dma/bcm-sba-raid.c
> +++ b/drivers/dma/bcm-sba-raid.c
> @@ -91,22 +91,23 @@
>  
>  /* = Driver data structures = */
>  
> -enum sba_request_state {
> - SBA_REQUEST_STATE_FREE = 1,
> - SBA_REQUEST_STATE_ALLOCED = 2,
> - SBA_REQUEST_STATE_PENDING = 3,
> - SBA_REQUEST_STATE_ACTIVE = 4,
> - SBA_REQUEST_STATE_RECEIVED = 5,
> - SBA_REQUEST_STATE_COMPLETED = 6,
> - SBA_REQUEST_STATE_ABORTED = 7,
> +enum sba_request_flags {
> + SBA_REQUEST_STATE_FREE  = 0x001,
> + SBA_REQUEST_STATE_ALLOCED   = 0x002,
> + SBA_REQUEST_STATE_PENDING   = 0x004,
> + SBA_REQUEST_STATE_ACTIVE= 0x008,
> + SBA_REQUEST_STATE_RECEIVED  = 0x010,
> + SBA_REQUEST_STATE_COMPLETED = 0x020,
> + SBA_REQUEST_STATE_ABORTED   = 0x040,
> + SBA_REQUEST_STATE_MASK  = 0x0ff,
> + SBA_REQUEST_FENCE   = 0x100,
>  };
>  
>  struct sba_request {
>   /* Global state */
>   struct list_head node;
>   struct sba_device *sba;
> - enum sba_request_state state;
> - bool fence;
> + u32 flags;
>   /* Chained requests management */
>   struct sba_request *first;
>   struct list_head next;
> @@ -217,8 +218,7 @@ static struct sba_request *sba_alloc_request(struct 
> sba_device *sba)
>   if (!req)
>   return NULL;
>  
> - req->state = SBA_REQUEST_STATE_ALLOCED;
> - req->fence = false;
> + req->flags = SBA_REQUEST_STATE_ALLOCED;
>   req->first = req;
>   INIT_LIST_HEAD(>next);
>   req->next_count = 1;
> @@ -234,7 +234,8 @@ static void _sba_pending_request(struct sba_device *sba,
>struct sba_request *req)
>  {
>   lockdep_assert_held(>reqs_lock);
> - req->state = SBA_REQUEST_STATE_PENDING;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_PENDING;
>   list_move_tail(>node, >reqs_pending_list);
>   if (list_empty(>reqs_active_list))
>   sba->reqs_fence = false;
> @@ -249,9 +250,10 @@ static bool _sba_active_request(struct sba_device *sba,
>   sba->reqs_fence = false;
>   if (sba->reqs_fence)
>   return false;
> - req->state = SBA_REQUEST_STATE_ACTIVE;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_ACTIVE;
>   list_move_tail(>node, >reqs_active_list);
> - if (req->fence)
> + if (req->flags & SBA_REQUEST_FENCE)
>   sba->reqs_fence = true;
>   return true;
>  }
> @@ -261,7 +263,8 @@ static void _sba_abort_request(struct sba_device *sba,
>  struct sba_request *req)
>  {
>   lockdep_assert_held(>reqs_lock);
> - req->state = SBA_REQUEST_STATE_ABORTED;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_ABORTED;
>   list_move_tail(>node, >reqs_aborted_list);
>   if (list_empty(>reqs_active_list))
>   sba->reqs_fence = false;
> @@ -272,7 +275,8 @@ static void _sba_free_request(struct sba_device *sba,
> struct sba_request *req)
>  {
>   lockdep_assert_held(>reqs_lock);
> - req->state = SBA_REQUEST_STATE_FREE;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_FREE;
>   list_move_tail(>node, >reqs_free_list);
>   if (list_empty(>reqs_active_list))
>   sba->reqs_fence = false;
> @@ -285,7 +289,8 @@ static void sba_received_request(struct sba_request *req)
>   struct sba_device *sba = req->sba;
>  
>   spin_lock_irqsave(>reqs_lock, flags);
> - req->state = SBA_REQUEST_STATE_RECEIVED;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_RECEIVED;
>   list_move_tail(>node, >reqs_received_list);
>   spin_unlock_irqrestore(>reqs_lock, flags);
>  }
> @@ -298,10 +303,12 @@ static void sba_complete_chained_requests(struct 
> sba_request *req)
>  
>   spin_lock_irqsave(>reqs_lock, flags);
>  
> - req->state = SBA_REQUEST_STATE_COMPLETED;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_COMPLETED;
>   list_move_tail(>node, >reqs_completed_list);
>   list_for_each_entry(nreq, >next, next) {
> - nreq->state = SBA_REQUEST_STATE_COMPLETED;
> + nreq->flags &= 

[PATCH V3 resend] cpufreq: Cap the default transition delay value to 10 ms

[Viresh Kumar]

If transition_delay_us isn't defined by the cpufreq driver, the default
value of transition delay (time after which the cpufreq governor will
try updating the frequency again) is currently calculated by multiplying
transition_latency (nsec) with LATENCY_MULTIPLIER (1000) and then
converting this time to usec. That gives the exact same value as
transition_latency, just that the time unit is usec instead of nsec.

With acpi-cpufreq for example, transition_latency is set to around 10
usec and we get transition delay as 10 ms. Which seems to be a
reasonable amount of time to reevaluate the frequency again.

But for platforms where frequency switching isn't that fast (like ARM),
the transition_latency varies from 500 usec to 3 ms, and the transition
delay becomes 500 ms to 3 seconds. Of course, that is a pretty bad
default value to start with.

We can try to come across a better formula (instead of multiplying with
LATENCY_MULTIPLIER) to solve this problem, but will that be worth it ?

This patch tries a simple approach and caps the maximum value of default
transition delay to 10 ms. Of course, userspace can still come in and
change this value anytime or individual drivers can rather provide
transition_delay_us instead.

Signed-off-by: Viresh Kumar 
---
One of the IMX shows odd behavior after this patch is applied and stays
at max freq for little longer. More detailed debugging is required to be
done by some IMX guys (who haven't replied for the last 3 weeks on that
email thread, apart from Leonard).

As per Leonard as well, we shouldn't stop this patch from getting merged
and so sending it again.

 drivers/cpufreq/cpufreq.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b2cc98551fc3..c7ae67d6886d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -532,8 +532,19 @@ unsigned int cpufreq_policy_transition_delay_us(struct 
cpufreq_policy *policy)
return policy->transition_delay_us;
 
latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
-   if (latency)
-   return latency * LATENCY_MULTIPLIER;
+   if (latency) {
+   /*
+* For platforms that can change the frequency very fast (< 10
+* us), the above formula gives a decent transition delay. But
+* for platforms where transition_latency is in milliseconds, it
+* ends up giving unrealistic values.
+*
+* Cap the default transition delay to 10 ms, which seems to be
+* a reasonable amount of time after which we should reevaluate
+* the frequency.
+*/
+   return min(latency * LATENCY_MULTIPLIER, (unsigned int)1);
+   }
 
return LATENCY_MULTIPLIER;
 }
-- 
2.14.1.202.g24db08a6e8fe

Re: [PATCH v2 03/16] dmaengine: bcm-sba-raid: Common flags for sba_request state and fence

[Vinod Koul]

On Tue, Aug 01, 2017 at 04:07:47PM +0530, Anup Patel wrote:
> This patch merges sba_request state and fence into common
> sba_request flags. Also, in-future we can extend sba_request
> flags as required.

and it also changes the flag values to bits, which I have no idea why that
was done, care to explain that please...

> 
> Signed-off-by: Anup Patel 
> ---
>  drivers/dma/bcm-sba-raid.c | 66 
> ++
>  1 file changed, 38 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
> index f81d5ac..6fa3df1 100644
> --- a/drivers/dma/bcm-sba-raid.c
> +++ b/drivers/dma/bcm-sba-raid.c
> @@ -91,22 +91,23 @@
>  
>  /* = Driver data structures = */
>  
> -enum sba_request_state {
> - SBA_REQUEST_STATE_FREE = 1,
> - SBA_REQUEST_STATE_ALLOCED = 2,
> - SBA_REQUEST_STATE_PENDING = 3,
> - SBA_REQUEST_STATE_ACTIVE = 4,
> - SBA_REQUEST_STATE_RECEIVED = 5,
> - SBA_REQUEST_STATE_COMPLETED = 6,
> - SBA_REQUEST_STATE_ABORTED = 7,
> +enum sba_request_flags {
> + SBA_REQUEST_STATE_FREE  = 0x001,
> + SBA_REQUEST_STATE_ALLOCED   = 0x002,
> + SBA_REQUEST_STATE_PENDING   = 0x004,
> + SBA_REQUEST_STATE_ACTIVE= 0x008,
> + SBA_REQUEST_STATE_RECEIVED  = 0x010,
> + SBA_REQUEST_STATE_COMPLETED = 0x020,
> + SBA_REQUEST_STATE_ABORTED   = 0x040,
> + SBA_REQUEST_STATE_MASK  = 0x0ff,
> + SBA_REQUEST_FENCE   = 0x100,
>  };
>  
>  struct sba_request {
>   /* Global state */
>   struct list_head node;
>   struct sba_device *sba;
> - enum sba_request_state state;
> - bool fence;
> + u32 flags;
>   /* Chained requests management */
>   struct sba_request *first;
>   struct list_head next;
> @@ -217,8 +218,7 @@ static struct sba_request *sba_alloc_request(struct 
> sba_device *sba)
>   if (!req)
>   return NULL;
>  
> - req->state = SBA_REQUEST_STATE_ALLOCED;
> - req->fence = false;
> + req->flags = SBA_REQUEST_STATE_ALLOCED;
>   req->first = req;
>   INIT_LIST_HEAD(>next);
>   req->next_count = 1;
> @@ -234,7 +234,8 @@ static void _sba_pending_request(struct sba_device *sba,
>struct sba_request *req)
>  {
>   lockdep_assert_held(>reqs_lock);
> - req->state = SBA_REQUEST_STATE_PENDING;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_PENDING;
>   list_move_tail(>node, >reqs_pending_list);
>   if (list_empty(>reqs_active_list))
>   sba->reqs_fence = false;
> @@ -249,9 +250,10 @@ static bool _sba_active_request(struct sba_device *sba,
>   sba->reqs_fence = false;
>   if (sba->reqs_fence)
>   return false;
> - req->state = SBA_REQUEST_STATE_ACTIVE;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_ACTIVE;
>   list_move_tail(>node, >reqs_active_list);
> - if (req->fence)
> + if (req->flags & SBA_REQUEST_FENCE)
>   sba->reqs_fence = true;
>   return true;
>  }
> @@ -261,7 +263,8 @@ static void _sba_abort_request(struct sba_device *sba,
>  struct sba_request *req)
>  {
>   lockdep_assert_held(>reqs_lock);
> - req->state = SBA_REQUEST_STATE_ABORTED;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_ABORTED;
>   list_move_tail(>node, >reqs_aborted_list);
>   if (list_empty(>reqs_active_list))
>   sba->reqs_fence = false;
> @@ -272,7 +275,8 @@ static void _sba_free_request(struct sba_device *sba,
> struct sba_request *req)
>  {
>   lockdep_assert_held(>reqs_lock);
> - req->state = SBA_REQUEST_STATE_FREE;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_FREE;
>   list_move_tail(>node, >reqs_free_list);
>   if (list_empty(>reqs_active_list))
>   sba->reqs_fence = false;
> @@ -285,7 +289,8 @@ static void sba_received_request(struct sba_request *req)
>   struct sba_device *sba = req->sba;
>  
>   spin_lock_irqsave(>reqs_lock, flags);
> - req->state = SBA_REQUEST_STATE_RECEIVED;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_RECEIVED;
>   list_move_tail(>node, >reqs_received_list);
>   spin_unlock_irqrestore(>reqs_lock, flags);
>  }
> @@ -298,10 +303,12 @@ static void sba_complete_chained_requests(struct 
> sba_request *req)
>  
>   spin_lock_irqsave(>reqs_lock, flags);
>  
> - req->state = SBA_REQUEST_STATE_COMPLETED;
> + req->flags &= ~SBA_REQUEST_STATE_MASK;
> + req->flags |= SBA_REQUEST_STATE_COMPLETED;
>   list_move_tail(>node, >reqs_completed_list);
>   list_for_each_entry(nreq, >next, next) {
> - nreq->state = SBA_REQUEST_STATE_COMPLETED;
> + nreq->flags &= ~SBA_REQUEST_STATE_MASK;
> +   

[PATCH V3 resend] cpufreq: Cap the default transition delay value to 10 ms

[Viresh Kumar]

If transition_delay_us isn't defined by the cpufreq driver, the default
value of transition delay (time after which the cpufreq governor will
try updating the frequency again) is currently calculated by multiplying
transition_latency (nsec) with LATENCY_MULTIPLIER (1000) and then
converting this time to usec. That gives the exact same value as
transition_latency, just that the time unit is usec instead of nsec.

With acpi-cpufreq for example, transition_latency is set to around 10
usec and we get transition delay as 10 ms. Which seems to be a
reasonable amount of time to reevaluate the frequency again.

But for platforms where frequency switching isn't that fast (like ARM),
the transition_latency varies from 500 usec to 3 ms, and the transition
delay becomes 500 ms to 3 seconds. Of course, that is a pretty bad
default value to start with.

We can try to come across a better formula (instead of multiplying with
LATENCY_MULTIPLIER) to solve this problem, but will that be worth it ?

This patch tries a simple approach and caps the maximum value of default
transition delay to 10 ms. Of course, userspace can still come in and
change this value anytime or individual drivers can rather provide
transition_delay_us instead.

Signed-off-by: Viresh Kumar 
---
One of the IMX shows odd behavior after this patch is applied and stays
at max freq for little longer. More detailed debugging is required to be
done by some IMX guys (who haven't replied for the last 3 weeks on that
email thread, apart from Leonard).

As per Leonard as well, we shouldn't stop this patch from getting merged
and so sending it again.

 drivers/cpufreq/cpufreq.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b2cc98551fc3..c7ae67d6886d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -532,8 +532,19 @@ unsigned int cpufreq_policy_transition_delay_us(struct 
cpufreq_policy *policy)
return policy->transition_delay_us;
 
latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
-   if (latency)
-   return latency * LATENCY_MULTIPLIER;
+   if (latency) {
+   /*
+* For platforms that can change the frequency very fast (< 10
+* us), the above formula gives a decent transition delay. But
+* for platforms where transition_latency is in milliseconds, it
+* ends up giving unrealistic values.
+*
+* Cap the default transition delay to 10 ms, which seems to be
+* a reasonable amount of time after which we should reevaluate
+* the frequency.
+*/
+   return min(latency * LATENCY_MULTIPLIER, (unsigned int)1);
+   }
 
return LATENCY_MULTIPLIER;
 }
-- 
2.14.1.202.g24db08a6e8fe

[PATCH] ARM: sun8i: a83t: Add device tree for Sinovoip Bananapi BPI-M3

[Chen-Yu Tsai]

The BPI-M3 is an Allwinner A83T based SBC in the Bananapi/Bpi family.
It is roughly the same form factor as the BPI-M1+, with roughly the
same peripherals and connectors:

  - 2GB LPDDR3 DRAM
  - 8GB eMMC
  - Micro-SD card slot
  - HDMI output
  - Headset (stereo + mic) jack
  - Onboard mic
  - Gigabit Ethernet with RTL8211E transceiver
  - Ampak AP6212 WiFi + BT
  - USB OTG connector
  - USB-to-SATA bridge connected through a USB 2.0 hub
  - Consumer IR receiver
  - MIPI DSI LCD panel connector
  - Camera interface (parallel and MIPI CSI) connector
  - 3 LEDs (Red, Green, Blue), of which 2 are controllable (GB)
  - Raspberry Pi 2 compatible GPIO header

Signed-off-by: Chen-Yu Tsai 
---

Note that the file name follows the convention of most of the other
bananapi boards, that is the vendor "sinovoip" is not included in
the name. This deviates from what is already in U-boot.

This applies on top of my A83t USB patches.

---
 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 148 +++
 2 files changed, 149 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e0d77ab79f5f..791fecc0774a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -903,6 +903,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
+   sun8i-a83t-bananapi-m3.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts 
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
new file mode 100644
index ..2bafd7e99ef7
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -0,0 +1,148 @@
+/*
+ * Copyright 2017 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a83t.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+
+/ {
+   model = "Banana Pi BPI-M3";
+   compatible = "sinovoip,bpi-m3", "allwinner,sun8i-a83t";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   /* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
+   status = "okay";
+
+   /* TODO GL830 USB-to-SATA bridge downstream w/ GPIO power controls */
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+   cd-inverted;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_8bit_emmc_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   

Re: [PATCH v2 01/16] dmaengine: bcm-sba-raid: Minor improvments in comments

[Vinod Koul]

On Tue, Aug 01, 2017 at 04:07:45PM +0530, Anup Patel wrote:
> Make section comments consistent across the Broadcom SBA RAID driver
> by avoiding " SBA " in some of the comments.

and you add more comments..

> 
> Signed-off-by: Anup Patel 
> ---
>  drivers/dma/bcm-sba-raid.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
> index e41bbc7..76999b7 100644
> --- a/drivers/dma/bcm-sba-raid.c
> +++ b/drivers/dma/bcm-sba-raid.c
> @@ -48,7 +48,8 @@
>  
>  #include "dmaengine.h"
>  
> -/* SBA command related defines */
> +/* == Driver macros and defines = */
> +
>  #define SBA_TYPE_SHIFT   48
>  #define SBA_TYPE_MASKGENMASK(1, 0)
>  #define SBA_TYPE_A   0x0
> @@ -88,6 +89,8 @@
>  #define to_sba_device(dchan) \
>   container_of(dchan, struct sba_device, dma_chan)
>  
> +/* = Driver data structures = */

like this!!

> +
>  enum sba_request_state {
>   SBA_REQUEST_STATE_FREE = 1,
>   SBA_REQUEST_STATE_ALLOCED = 2,
> @@ -164,7 +167,7 @@ struct sba_device {
>   int reqs_free_count;
>  };
>  
> -/* == SBA command helper routines = */
> +/* == Command helper routines = */
>  
>  static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
>  {
> @@ -196,7 +199,7 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 
> b1, u32 b0)
>  ((d & SBA_C_MDATA_DNUM_MASK) << SBA_C_MDATA_DNUM_SHIFT);
>  }
>  
> -/* == Channel resource management routines = */
> +/* == General helper routines = */
>  
>  static struct sba_request *sba_alloc_request(struct sba_device *sba)
>  {
> -- 
> 2.7.4
> 

-- 
~Vinod

[PATCH] ARM: sun8i: a83t: Add device tree for Sinovoip Bananapi BPI-M3

[Chen-Yu Tsai]

The BPI-M3 is an Allwinner A83T based SBC in the Bananapi/Bpi family.
It is roughly the same form factor as the BPI-M1+, with roughly the
same peripherals and connectors:

  - 2GB LPDDR3 DRAM
  - 8GB eMMC
  - Micro-SD card slot
  - HDMI output
  - Headset (stereo + mic) jack
  - Onboard mic
  - Gigabit Ethernet with RTL8211E transceiver
  - Ampak AP6212 WiFi + BT
  - USB OTG connector
  - USB-to-SATA bridge connected through a USB 2.0 hub
  - Consumer IR receiver
  - MIPI DSI LCD panel connector
  - Camera interface (parallel and MIPI CSI) connector
  - 3 LEDs (Red, Green, Blue), of which 2 are controllable (GB)
  - Raspberry Pi 2 compatible GPIO header

Signed-off-by: Chen-Yu Tsai 
---

Note that the file name follows the convention of most of the other
bananapi boards, that is the vendor "sinovoip" is not included in
the name. This deviates from what is already in U-boot.

This applies on top of my A83t USB patches.

---
 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 148 +++
 2 files changed, 149 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e0d77ab79f5f..791fecc0774a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -903,6 +903,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
+   sun8i-a83t-bananapi-m3.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts 
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
new file mode 100644
index ..2bafd7e99ef7
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -0,0 +1,148 @@
+/*
+ * Copyright 2017 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a83t.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+
+/ {
+   model = "Banana Pi BPI-M3";
+   compatible = "sinovoip,bpi-m3", "allwinner,sun8i-a83t";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   /* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
+   status = "okay";
+
+   /* TODO GL830 USB-to-SATA bridge downstream w/ GPIO power controls */
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+   cd-inverted;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_8bit_emmc_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   status = "okay";
+};
+
+_rsb {
+   status = "okay";
+
+   axp81x: pmic@3a3 {
+   

Re: [PATCH v2 01/16] dmaengine: bcm-sba-raid: Minor improvments in comments

[Vinod Koul]

On Tue, Aug 01, 2017 at 04:07:45PM +0530, Anup Patel wrote:
> Make section comments consistent across the Broadcom SBA RAID driver
> by avoiding " SBA " in some of the comments.

and you add more comments..

> 
> Signed-off-by: Anup Patel 
> ---
>  drivers/dma/bcm-sba-raid.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
> index e41bbc7..76999b7 100644
> --- a/drivers/dma/bcm-sba-raid.c
> +++ b/drivers/dma/bcm-sba-raid.c
> @@ -48,7 +48,8 @@
>  
>  #include "dmaengine.h"
>  
> -/* SBA command related defines */
> +/* == Driver macros and defines = */
> +
>  #define SBA_TYPE_SHIFT   48
>  #define SBA_TYPE_MASKGENMASK(1, 0)
>  #define SBA_TYPE_A   0x0
> @@ -88,6 +89,8 @@
>  #define to_sba_device(dchan) \
>   container_of(dchan, struct sba_device, dma_chan)
>  
> +/* = Driver data structures = */

like this!!

> +
>  enum sba_request_state {
>   SBA_REQUEST_STATE_FREE = 1,
>   SBA_REQUEST_STATE_ALLOCED = 2,
> @@ -164,7 +167,7 @@ struct sba_device {
>   int reqs_free_count;
>  };
>  
> -/* == SBA command helper routines = */
> +/* == Command helper routines = */
>  
>  static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
>  {
> @@ -196,7 +199,7 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 
> b1, u32 b0)
>  ((d & SBA_C_MDATA_DNUM_MASK) << SBA_C_MDATA_DNUM_SHIFT);
>  }
>  
> -/* == Channel resource management routines = */
> +/* == General helper routines = */
>  
>  static struct sba_request *sba_alloc_request(struct sba_device *sba)
>  {
> -- 
> 2.7.4
> 

-- 
~Vinod

Re: [PATCH 1/2 v6] time: Make fast functions return 0 before timekeeping is initialized

[John Stultz]

On Wed, Aug 16, 2017 at 8:17 AM, Prarit Bhargava  wrote:
> printk timestamps will be extended to include mono and boot time by using
> the fast timekeeping functions ktime_get_mono|boot_fast_ns() functions.
> The functions can return garbage before timekeeping is initialized
> resulting in garbage timestamps.
>
> The fast time functions must return 0 before timekeeping is initialized.
>

This looks reasonable. I can queue it, but you still have feedback to
address on 2/2, so I may wait until that is sorted.

thanks
-john

Re: [PATCH 1/2 v6] time: Make fast functions return 0 before timekeeping is initialized

[John Stultz]

On Wed, Aug 16, 2017 at 8:17 AM, Prarit Bhargava  wrote:
> printk timestamps will be extended to include mono and boot time by using
> the fast timekeeping functions ktime_get_mono|boot_fast_ns() functions.
> The functions can return garbage before timekeeping is initialized
> resulting in garbage timestamps.
>
> The fast time functions must return 0 before timekeeping is initialized.
>

This looks reasonable. I can queue it, but you still have feedback to
address on 2/2, so I may wait until that is sorted.

thanks
-john

Re: [PATCH v4 5/6] perf: hisi: Add support for HiSilicon SoC DDRC PMU driver

[Zhangshaokun]

Hi Mark,

On 2017/8/15 21:02, Mark Rutland wrote:
> On Tue, Jul 25, 2017 at 08:10:41PM +0800, Shaokun Zhang wrote:
>> This patch adds support for DDRC PMU driver in HiSilicon SoC chip, Each
>> DDRC has own control, counter and interrupt registers and is an separate
>> PMU. For each DDRC PMU, it has 8-fixed-purpose counters which have been
>> mapped to 8-events by hardware, it assumes that counter index is equal
>> to event code (0 - 7) in DDRC PMU driver. Interrupt is supported to
>> handle counter (32-bits) overflow.
>>
>> Reviewed-by: Jonathan Cameron 
>> Signed-off-by: Shaokun Zhang 
>> Signed-off-by: Anurup M 
>> ---
>>  drivers/perf/hisilicon/Makefile   |   2 +-
>>  drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 420 
>> ++
>>  2 files changed, 421 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
> 
> My comments for the HHA PMU driver all apply here, too.
> 

Surely.

Thanks.
Shaokun

> Thanks,
> Mark.
> 
>> diff --git a/drivers/perf/hisilicon/Makefile 
>> b/drivers/perf/hisilicon/Makefile
>> index a72afe8..2621d51 100644
>> --- a/drivers/perf/hisilicon/Makefile
>> +++ b/drivers/perf/hisilicon/Makefile
>> @@ -1 +1 @@
>> -obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o 
>> hisi_uncore_hha_pmu.o
>> +obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o 
>> hisi_uncore_hha_pmu.o hisi_uncore_ddrc_pmu.o
>> diff --git a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c 
>> b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
>> new file mode 100644
>> index 000..e178a09
>> --- /dev/null
>> +++ b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
>> @@ -0,0 +1,420 @@
>> +/*
>> + * HiSilicon SoC DDRC uncore Hardware event counters support
>> + *
>> + * Copyright (C) 2017 Hisilicon Limited
>> + * Author: Shaokun Zhang 
>> + * Anurup M 
>> + *
>> + * This code is based on the uncore PMUs like arm-cci and arm-ccn.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include "hisi_uncore_pmu.h"
>> +
>> +/* DDRC register definition */
>> +#define DDRC_PERF_CTRL  0x010
>> +#define DDRC_FLUX_WR0x380
>> +#define DDRC_FLUX_RD0x384
>> +#define DDRC_FLUX_WCMD  0x388
>> +#define DDRC_FLUX_RCMD  0x38c
>> +#define DDRC_PRE_CMD0x3c0
>> +#define DDRC_ACT_CMD0x3c4
>> +#define DDRC_BNK_CHG0x3c8
>> +#define DDRC_RNK_CHG0x3cc
>> +#define DDRC_EVENT_CTRL 0x6C0
>> +#define DDRC_INT_MASK   0x6c8
>> +#define DDRC_INT_STATUS 0x6cc
>> +#define DDRC_INT_CLEAR  0x6d0
>> +
>> +/* DDRC supports 8-events and counter is fixed-purpose */
>> +#define DDRC_NR_COUNTERS0x8
>> +#define DDRC_NR_EVENTS  DDRC_NR_COUNTERS
>> +
>> +#define DDRC_PERF_CTRL_EN   0x2
>> +
>> +/*
>> + * For DDRC PMU, there are eight-events and every event has been mapped
>> + * to fixed-purpose counters which register offset is not consistent.
>> + * Therefore there is no write event type and we assume that event
>> + * code (0 to 7) is equal to counter index in PMU driver.
>> + */
>> +#define GET_DDRC_EVENTID(hwc)   (hwc->config_base & 0x7)
>> +
>> +static const u32 ddrc_reg_off[] = {
>> +DDRC_FLUX_WR, DDRC_FLUX_RD, DDRC_FLUX_WCMD, DDRC_FLUX_RCMD,
>> +DDRC_PRE_CMD, DDRC_ACT_CMD, DDRC_BNK_CHG, DDRC_RNK_CHG
>> +};
>> +
>> +/*
>> + * Select the counter register offset using the counter index.
>> + * In DDRC there are no programmable counter, the count
>> + * is readed form the statistics counter register itself.
>> + */
>> +static u32 get_counter_reg_off(int cntr_idx)
>> +{
>> +return ddrc_reg_off[cntr_idx];
>> +}
>> +
>> +static u64 hisi_ddrc_pmu_read_counter(struct hisi_pmu *ddrc_pmu,
>> +  struct hw_perf_event *hwc)
>> +{
>> +/* Use event code as counter index */
>> +u32 idx = GET_DDRC_EVENTID(hwc);
>> +u32 reg;
>> +
>> +if (!hisi_uncore_pmu_counter_valid(ddrc_pmu, idx)) {
>> +dev_err(ddrc_pmu->dev, "Unsupported event index:%d!\n", idx);
>> +return 0;
>> +}
>> +
>> +reg = get_counter_reg_off(idx);
>> +
>> +return readl(ddrc_pmu->base + reg);
>> +}
>> +
>> +static void hisi_ddrc_pmu_write_counter(struct hisi_pmu *ddrc_pmu,
>> +struct hw_perf_event *hwc, u64 val)
>> +{
>> +u32 idx = GET_DDRC_EVENTID(hwc);
>> +u32 reg;
>> +
>> +if (!hisi_uncore_pmu_counter_valid(ddrc_pmu, idx)) {
>> +dev_err(ddrc_pmu->dev, "Unsupported event index:%d!\n", idx);
>> +return;
>> 

Re: [PATCH v4 5/6] perf: hisi: Add support for HiSilicon SoC DDRC PMU driver

[Zhangshaokun]

Hi Mark,

On 2017/8/15 21:02, Mark Rutland wrote:
> On Tue, Jul 25, 2017 at 08:10:41PM +0800, Shaokun Zhang wrote:
>> This patch adds support for DDRC PMU driver in HiSilicon SoC chip, Each
>> DDRC has own control, counter and interrupt registers and is an separate
>> PMU. For each DDRC PMU, it has 8-fixed-purpose counters which have been
>> mapped to 8-events by hardware, it assumes that counter index is equal
>> to event code (0 - 7) in DDRC PMU driver. Interrupt is supported to
>> handle counter (32-bits) overflow.
>>
>> Reviewed-by: Jonathan Cameron 
>> Signed-off-by: Shaokun Zhang 
>> Signed-off-by: Anurup M 
>> ---
>>  drivers/perf/hisilicon/Makefile   |   2 +-
>>  drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 420 
>> ++
>>  2 files changed, 421 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
> 
> My comments for the HHA PMU driver all apply here, too.
> 

Surely.

Thanks.
Shaokun

> Thanks,
> Mark.
> 
>> diff --git a/drivers/perf/hisilicon/Makefile 
>> b/drivers/perf/hisilicon/Makefile
>> index a72afe8..2621d51 100644
>> --- a/drivers/perf/hisilicon/Makefile
>> +++ b/drivers/perf/hisilicon/Makefile
>> @@ -1 +1 @@
>> -obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o 
>> hisi_uncore_hha_pmu.o
>> +obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o 
>> hisi_uncore_hha_pmu.o hisi_uncore_ddrc_pmu.o
>> diff --git a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c 
>> b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
>> new file mode 100644
>> index 000..e178a09
>> --- /dev/null
>> +++ b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
>> @@ -0,0 +1,420 @@
>> +/*
>> + * HiSilicon SoC DDRC uncore Hardware event counters support
>> + *
>> + * Copyright (C) 2017 Hisilicon Limited
>> + * Author: Shaokun Zhang 
>> + * Anurup M 
>> + *
>> + * This code is based on the uncore PMUs like arm-cci and arm-ccn.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include "hisi_uncore_pmu.h"
>> +
>> +/* DDRC register definition */
>> +#define DDRC_PERF_CTRL  0x010
>> +#define DDRC_FLUX_WR0x380
>> +#define DDRC_FLUX_RD0x384
>> +#define DDRC_FLUX_WCMD  0x388
>> +#define DDRC_FLUX_RCMD  0x38c
>> +#define DDRC_PRE_CMD0x3c0
>> +#define DDRC_ACT_CMD0x3c4
>> +#define DDRC_BNK_CHG0x3c8
>> +#define DDRC_RNK_CHG0x3cc
>> +#define DDRC_EVENT_CTRL 0x6C0
>> +#define DDRC_INT_MASK   0x6c8
>> +#define DDRC_INT_STATUS 0x6cc
>> +#define DDRC_INT_CLEAR  0x6d0
>> +
>> +/* DDRC supports 8-events and counter is fixed-purpose */
>> +#define DDRC_NR_COUNTERS0x8
>> +#define DDRC_NR_EVENTS  DDRC_NR_COUNTERS
>> +
>> +#define DDRC_PERF_CTRL_EN   0x2
>> +
>> +/*
>> + * For DDRC PMU, there are eight-events and every event has been mapped
>> + * to fixed-purpose counters which register offset is not consistent.
>> + * Therefore there is no write event type and we assume that event
>> + * code (0 to 7) is equal to counter index in PMU driver.
>> + */
>> +#define GET_DDRC_EVENTID(hwc)   (hwc->config_base & 0x7)
>> +
>> +static const u32 ddrc_reg_off[] = {
>> +DDRC_FLUX_WR, DDRC_FLUX_RD, DDRC_FLUX_WCMD, DDRC_FLUX_RCMD,
>> +DDRC_PRE_CMD, DDRC_ACT_CMD, DDRC_BNK_CHG, DDRC_RNK_CHG
>> +};
>> +
>> +/*
>> + * Select the counter register offset using the counter index.
>> + * In DDRC there are no programmable counter, the count
>> + * is readed form the statistics counter register itself.
>> + */
>> +static u32 get_counter_reg_off(int cntr_idx)
>> +{
>> +return ddrc_reg_off[cntr_idx];
>> +}
>> +
>> +static u64 hisi_ddrc_pmu_read_counter(struct hisi_pmu *ddrc_pmu,
>> +  struct hw_perf_event *hwc)
>> +{
>> +/* Use event code as counter index */
>> +u32 idx = GET_DDRC_EVENTID(hwc);
>> +u32 reg;
>> +
>> +if (!hisi_uncore_pmu_counter_valid(ddrc_pmu, idx)) {
>> +dev_err(ddrc_pmu->dev, "Unsupported event index:%d!\n", idx);
>> +return 0;
>> +}
>> +
>> +reg = get_counter_reg_off(idx);
>> +
>> +return readl(ddrc_pmu->base + reg);
>> +}
>> +
>> +static void hisi_ddrc_pmu_write_counter(struct hisi_pmu *ddrc_pmu,
>> +struct hw_perf_event *hwc, u64 val)
>> +{
>> +u32 idx = GET_DDRC_EVENTID(hwc);
>> +u32 reg;
>> +
>> +if (!hisi_uncore_pmu_counter_valid(ddrc_pmu, idx)) {
>> +dev_err(ddrc_pmu->dev, "Unsupported event index:%d!\n", idx);
>> +return;
>> +}
>> +
>> +reg = get_counter_reg_off(idx);
>> +writel((u32)val, ddrc_pmu->base + reg);
>> +}
>> +
>> +static void 

[PATCH v14 4/5] mm: support reporting free page blocks

[Wei Wang]

This patch adds support to walk through the free page blocks in the
system and report them via a callback function. Some page blocks may
leave the free list after zone->lock is released, so it is the caller's
responsibility to either detect or prevent the use of such pages.

Signed-off-by: Wei Wang 
Signed-off-by: Liang Li 
Cc: Michal Hocko 
Cc: Michael S. Tsirkin 
---
 include/linux/mm.h |  6 ++
 mm/page_alloc.c| 44 
 2 files changed, 50 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 46b9ac5..cd29b9f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1835,6 +1835,12 @@ extern void free_area_init_node(int nid, unsigned long * 
zones_size,
unsigned long zone_start_pfn, unsigned long *zholes_size);
 extern void free_initmem(void);
 
+extern void walk_free_mem_block(void *opaque1,
+   unsigned int min_order,
+   void (*visit)(void *opaque2,
+ unsigned long pfn,
+ unsigned long nr_pages));
+
 /*
  * Free reserved pages within range [PAGE_ALIGN(start), end & PAGE_MASK)
  * into the buddy system. The freed pages will be poisoned with pattern
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6d00f74..a721a35 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4762,6 +4762,50 @@ void show_free_areas(unsigned int filter, nodemask_t 
*nodemask)
show_swap_cache_info();
 }
 
+/**
+ * walk_free_mem_block - Walk through the free page blocks in the system
+ * @opaque1: the context passed from the caller
+ * @min_order: the minimum order of free lists to check
+ * @visit: the callback function given by the caller
+ *
+ * The function is used to walk through the free page blocks in the system,
+ * and each free page block is reported to the caller via the @visit callback.
+ * Please note:
+ * 1) The function is used to report hints of free pages, so the caller should
+ * not use those reported pages after the callback returns.
+ * 2) The callback is invoked with the zone->lock being held, so it should not
+ * block and should finish as soon as possible.
+ */
+void walk_free_mem_block(void *opaque1,
+unsigned int min_order,
+void (*visit)(void *opaque2,
+  unsigned long pfn,
+  unsigned long nr_pages))
+{
+   struct zone *zone;
+   struct page *page;
+   struct list_head *list;
+   unsigned int order;
+   enum migratetype mt;
+   unsigned long pfn, flags;
+
+   for_each_populated_zone(zone) {
+   for (order = MAX_ORDER - 1;
+order < MAX_ORDER && order >= min_order; order--) {
+   for (mt = 0; mt < MIGRATE_TYPES; mt++) {
+   spin_lock_irqsave(>lock, flags);
+   list = >free_area[order].free_list[mt];
+   list_for_each_entry(page, list, lru) {
+   pfn = page_to_pfn(page);
+   visit(opaque1, pfn, 1 << order);
+   }
+   spin_unlock_irqrestore(>lock, flags);
+   }
+   }
+   }
+}
+EXPORT_SYMBOL_GPL(walk_free_mem_block);
+
 static void zoneref_set_zone(struct zone *zone, struct zoneref *zoneref)
 {
zoneref->zone = zone;
-- 
2.7.4

Re: [PATCH v4 4/6] perf: hisi: Add support for HiSilicon SoC HHA PMU driver

[Zhangshaokun]

Hi Mark,

On 2017/8/15 19:05, Mark Rutland wrote:
> On Tue, Jul 25, 2017 at 08:10:40PM +0800, Shaokun Zhang wrote:
>> +/* HHA register definition */
>> +#define HHA_INT_MASK0x0804
>> +#define HHA_INT_STATUS  0x0808
>> +#define HHA_INT_CLEAR   0x080C
>> +#define HHA_PERF_CTRL   0x1E00
>> +#define HHA_EVENT_CTRL  0x1E04
>> +#define HHA_EVENT_TYPE0 0x1E80
>> +#define HHA_CNT0_LOWER  0x1F00
>> +
>> +/* HHA has 16-counters and supports 0x50 events */
> 
> As with the L3C PMU, what exactly does this mean?
> 
> Does this mean event IDs 0-0x4f are valid?
> 

It is the same as L3C PMU and it is event IDs.

> [...]
> 
>> +static irqreturn_t hisi_hha_pmu_isr(int irq, void *dev_id)
>> +{
>> +struct hisi_pmu *hha_pmu = dev_id;
>> +struct perf_event *event;
>> +unsigned long overflown;
>> +u32 status;
>> +int idx;
>> +
>> +/* Read HHA_INT_STATUS register */
>> +status = readl(hha_pmu->base + HHA_INT_STATUS);
>> +if (!status)
>> +return IRQ_NONE;
>> +overflown = status;
> 
> No need for the u32 temporary here.
> 

Ok.

> []
> 
>> +static int hisi_hha_pmu_dev_probe(struct platform_device *pdev,
>> +  struct hisi_pmu *hha_pmu)
>> +{
>> +struct device *dev = >dev;
>> +int ret;
>> +
>> +ret = hisi_hha_pmu_init_data(pdev, hha_pmu);
>> +if (ret)
>> +return ret;
>> +
>> +/* Pick one core to use for cpumask attributes */
>> +cpumask_set_cpu(smp_processor_id(), _pmu->cpus);
>> +
> 
> Why does this not have the usual event migration callbacks, across CPUs
> in the same SCCL?
> 

Sorry we missed this. Shall add CPU hotplug callbacks and handle the cpumask
update and event migration.

>> +ret = hisi_hha_pmu_init_irq(hha_pmu, pdev);
>> +if (ret)
>> +return ret;
>> +
>> +hha_pmu->name = devm_kasprintf(dev, GFP_KERNEL, "hisi_hha%u_%u",
>> +   hha_pmu->hha_uid, hha_pmu->sccl_id);
> 
> As on the doc patch, this should be hierarchical.
> 

Surely.

Thanks,
Shaokun

> Thanks,
> Mark
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 

[PATCH v14 4/5] mm: support reporting free page blocks

[Wei Wang]

This patch adds support to walk through the free page blocks in the
system and report them via a callback function. Some page blocks may
leave the free list after zone->lock is released, so it is the caller's
responsibility to either detect or prevent the use of such pages.

Signed-off-by: Wei Wang 
Signed-off-by: Liang Li 
Cc: Michal Hocko 
Cc: Michael S. Tsirkin 
---
 include/linux/mm.h |  6 ++
 mm/page_alloc.c| 44 
 2 files changed, 50 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 46b9ac5..cd29b9f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1835,6 +1835,12 @@ extern void free_area_init_node(int nid, unsigned long * 
zones_size,
unsigned long zone_start_pfn, unsigned long *zholes_size);
 extern void free_initmem(void);
 
+extern void walk_free_mem_block(void *opaque1,
+   unsigned int min_order,
+   void (*visit)(void *opaque2,
+ unsigned long pfn,
+ unsigned long nr_pages));
+
 /*
  * Free reserved pages within range [PAGE_ALIGN(start), end & PAGE_MASK)
  * into the buddy system. The freed pages will be poisoned with pattern
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6d00f74..a721a35 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4762,6 +4762,50 @@ void show_free_areas(unsigned int filter, nodemask_t 
*nodemask)
show_swap_cache_info();
 }
 
+/**
+ * walk_free_mem_block - Walk through the free page blocks in the system
+ * @opaque1: the context passed from the caller
+ * @min_order: the minimum order of free lists to check
+ * @visit: the callback function given by the caller
+ *
+ * The function is used to walk through the free page blocks in the system,
+ * and each free page block is reported to the caller via the @visit callback.
+ * Please note:
+ * 1) The function is used to report hints of free pages, so the caller should
+ * not use those reported pages after the callback returns.
+ * 2) The callback is invoked with the zone->lock being held, so it should not
+ * block and should finish as soon as possible.
+ */
+void walk_free_mem_block(void *opaque1,
+unsigned int min_order,
+void (*visit)(void *opaque2,
+  unsigned long pfn,
+  unsigned long nr_pages))
+{
+   struct zone *zone;
+   struct page *page;
+   struct list_head *list;
+   unsigned int order;
+   enum migratetype mt;
+   unsigned long pfn, flags;
+
+   for_each_populated_zone(zone) {
+   for (order = MAX_ORDER - 1;
+order < MAX_ORDER && order >= min_order; order--) {
+   for (mt = 0; mt < MIGRATE_TYPES; mt++) {
+   spin_lock_irqsave(>lock, flags);
+   list = >free_area[order].free_list[mt];
+   list_for_each_entry(page, list, lru) {
+   pfn = page_to_pfn(page);
+   visit(opaque1, pfn, 1 << order);
+   }
+   spin_unlock_irqrestore(>lock, flags);
+   }
+   }
+   }
+}
+EXPORT_SYMBOL_GPL(walk_free_mem_block);
+
 static void zoneref_set_zone(struct zone *zone, struct zoneref *zoneref)
 {
zoneref->zone = zone;
-- 
2.7.4

Re: [PATCH v4 4/6] perf: hisi: Add support for HiSilicon SoC HHA PMU driver

[Zhangshaokun]

Hi Mark,

On 2017/8/15 19:05, Mark Rutland wrote:
> On Tue, Jul 25, 2017 at 08:10:40PM +0800, Shaokun Zhang wrote:
>> +/* HHA register definition */
>> +#define HHA_INT_MASK0x0804
>> +#define HHA_INT_STATUS  0x0808
>> +#define HHA_INT_CLEAR   0x080C
>> +#define HHA_PERF_CTRL   0x1E00
>> +#define HHA_EVENT_CTRL  0x1E04
>> +#define HHA_EVENT_TYPE0 0x1E80
>> +#define HHA_CNT0_LOWER  0x1F00
>> +
>> +/* HHA has 16-counters and supports 0x50 events */
> 
> As with the L3C PMU, what exactly does this mean?
> 
> Does this mean event IDs 0-0x4f are valid?
> 

It is the same as L3C PMU and it is event IDs.

> [...]
> 
>> +static irqreturn_t hisi_hha_pmu_isr(int irq, void *dev_id)
>> +{
>> +struct hisi_pmu *hha_pmu = dev_id;
>> +struct perf_event *event;
>> +unsigned long overflown;
>> +u32 status;
>> +int idx;
>> +
>> +/* Read HHA_INT_STATUS register */
>> +status = readl(hha_pmu->base + HHA_INT_STATUS);
>> +if (!status)
>> +return IRQ_NONE;
>> +overflown = status;
> 
> No need for the u32 temporary here.
> 

Ok.

> []
> 
>> +static int hisi_hha_pmu_dev_probe(struct platform_device *pdev,
>> +  struct hisi_pmu *hha_pmu)
>> +{
>> +struct device *dev = >dev;
>> +int ret;
>> +
>> +ret = hisi_hha_pmu_init_data(pdev, hha_pmu);
>> +if (ret)
>> +return ret;
>> +
>> +/* Pick one core to use for cpumask attributes */
>> +cpumask_set_cpu(smp_processor_id(), _pmu->cpus);
>> +
> 
> Why does this not have the usual event migration callbacks, across CPUs
> in the same SCCL?
> 

Sorry we missed this. Shall add CPU hotplug callbacks and handle the cpumask
update and event migration.

>> +ret = hisi_hha_pmu_init_irq(hha_pmu, pdev);
>> +if (ret)
>> +return ret;
>> +
>> +hha_pmu->name = devm_kasprintf(dev, GFP_KERNEL, "hisi_hha%u_%u",
>> +   hha_pmu->hha_uid, hha_pmu->sccl_id);
> 
> As on the doc patch, this should be hierarchical.
> 

Surely.

Thanks,
Shaokun

> Thanks,
> Mark
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 

[PATCH v14 5/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

[Wei Wang]

Add a new vq to report hints of guest free pages to the host.

Signed-off-by: Wei Wang 
Signed-off-by: Liang Li 
---
 drivers/virtio/virtio_balloon.c | 167 +++-
 include/uapi/linux/virtio_balloon.h |   1 +
 2 files changed, 147 insertions(+), 21 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 72041b4..e6755bc 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -54,11 +54,12 @@ static struct vfsmount *balloon_mnt;
 
 struct virtio_balloon {
struct virtio_device *vdev;
-   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
+   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
 
/* The balloon servicing is delegated to a freezable workqueue. */
struct work_struct update_balloon_stats_work;
struct work_struct update_balloon_size_work;
+   struct work_struct report_free_page_work;
 
/* Prevent updating balloon when it is being canceled. */
spinlock_t stop_update_lock;
@@ -90,6 +91,13 @@ struct virtio_balloon {
/* Memory statistics */
struct virtio_balloon_stat stats[VIRTIO_BALLOON_S_NR];
 
+   /*
+* Used by the device and driver to signal each other.
+* device->driver: start the free page report.
+* driver->device: end the free page report.
+*/
+   __virtio32 report_free_page_signal;
+
/* To register callback in oom notifier call chain */
struct notifier_block nb;
 };
@@ -174,6 +182,17 @@ static void send_balloon_page_sg(struct virtio_balloon *vb,
} while (unlikely(ret == -ENOSPC));
 }
 
+static void send_free_page_sg(struct virtqueue *vq, void *addr, uint32_t size)
+{
+   unsigned int len;
+
+   add_one_sg(vq, addr, size);
+   virtqueue_kick(vq);
+   /* Release entries if there are */
+   while (virtqueue_get_buf(vq, ))
+   ;
+}
+
 /*
  * Send balloon pages in sgs to host. The balloon pages are recorded in the
  * page xbitmap. Each bit in the bitmap corresponds to a page of PAGE_SIZE.
@@ -511,42 +530,143 @@ static void update_balloon_size_func(struct work_struct 
*work)
queue_work(system_freezable_wq, work);
 }
 
+static void virtio_balloon_send_free_pages(void *opaque, unsigned long pfn,
+  unsigned long nr_pages)
+{
+   struct virtio_balloon *vb = (struct virtio_balloon *)opaque;
+   void *addr = (void *)pfn_to_kaddr(pfn);
+   uint32_t len = nr_pages << PAGE_SHIFT;
+
+   send_free_page_sg(vb->free_page_vq, addr, len);
+}
+
+static void report_free_page_completion(struct virtio_balloon *vb)
+{
+   struct virtqueue *vq = vb->free_page_vq;
+   struct scatterlist sg;
+   unsigned int len;
+   int ret;
+
+   sg_init_one(, >report_free_page_signal, sizeof(__virtio32));
+retry:
+   ret = virtqueue_add_outbuf(vq, , 1, vb, GFP_KERNEL);
+   virtqueue_kick(vq);
+   if (unlikely(ret == -ENOSPC)) {
+   wait_event(vb->acked, virtqueue_get_buf(vq, ));
+   goto retry;
+   }
+}
+
+static void report_free_page(struct work_struct *work)
+{
+   struct virtio_balloon *vb;
+
+   vb = container_of(work, struct virtio_balloon, report_free_page_work);
+   walk_free_mem_block(vb, 0, _balloon_send_free_pages);
+   report_free_page_completion(vb);
+}
+
+static void free_page_request(struct virtqueue *vq)
+{
+   struct virtio_balloon *vb = vq->vdev->priv;
+
+   queue_work(system_freezable_wq, >report_free_page_work);
+}
+
 static int init_vqs(struct virtio_balloon *vb)
 {
-   struct virtqueue *vqs[3];
-   vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request 
};
-   static const char * const names[] = { "inflate", "deflate", "stats" };
-   int err, nvqs;
+   struct virtqueue **vqs;
+   vq_callback_t **callbacks;
+   const char **names;
+   struct scatterlist sg;
+   int i, nvqs, err = -ENOMEM;
+
+   /* Inflateq and deflateq are used unconditionally */
+   nvqs = 2;
+   if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ))
+   nvqs++;
+   if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ))
+   nvqs++;
+
+   /* Allocate space for find_vqs parameters */
+   vqs = kcalloc(nvqs, sizeof(*vqs), GFP_KERNEL);
+   if (!vqs)
+   goto err_vq;
+   callbacks = kmalloc_array(nvqs, sizeof(*callbacks), GFP_KERNEL);
+   if (!callbacks)
+   goto err_callback;
+   names = kmalloc_array(nvqs, sizeof(*names), GFP_KERNEL);
+   if (!names)
+   goto err_names;
+
+   callbacks[0] = balloon_ack;
+   names[0] = "inflate";
+   callbacks[1] = balloon_ack;
+   names[1] = "deflate";
+
+   i = 2;
+   if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
+  

[PATCH v14 3/5] virtio-balloon: VIRTIO_BALLOON_F_SG

[Wei Wang]

Add a new feature, VIRTIO_BALLOON_F_SG, which enables the transfer
of balloon (i.e. inflated/deflated) pages using scatter-gather lists
to the host.

The implementation of the previous virtio-balloon is not very
efficient, because the balloon pages are transferred to the
host one by one. Here is the breakdown of the time in percentage
spent on each step of the balloon inflating process (inflating
7GB of an 8GB idle guest).

1) allocating pages (6.5%)
2) sending PFNs to host (68.3%)
3) address translation (6.1%)
4) madvise (19%)

It takes about 4126ms for the inflating process to complete.
The above profiling shows that the bottlenecks are stage 2)
and stage 4).

This patch optimizes step 2) by transferring pages to the host in
sgs. An sg describes a chunk of guest physically continuous pages.
With this mechanism, step 4) can also be optimized by doing address
translation and madvise() in chunks rather than page by page.

With this new feature, the above ballooning process takes ~541ms
resulting in an improvement of ~87%.

TODO: optimize stage 1) by allocating/freeing a chunk of pages
instead of a single page each time.

Signed-off-by: Wei Wang 
Signed-off-by: Liang Li 
Suggested-by: Michael S. Tsirkin 
---
 drivers/virtio/virtio_balloon.c | 157 
 include/uapi/linux/virtio_balloon.h |   1 +
 2 files changed, 141 insertions(+), 17 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index f0b3a0b..72041b4 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Balloon device works in 4K page units.  So each page is pointed to by
@@ -79,6 +80,9 @@ struct virtio_balloon {
/* Synchronize access/update to this struct virtio_balloon elements */
struct mutex balloon_lock;
 
+   /* The xbitmap used to record ballooned pages */
+   struct xb page_xb;
+
/* The array of pfns we tell the Host about. */
unsigned int num_pfns;
__virtio32 pfns[VIRTIO_BALLOON_ARRAY_PFNS_MAX];
@@ -141,13 +145,98 @@ static void set_page_pfns(struct virtio_balloon *vb,
  page_to_balloon_pfn(page) + i);
 }
 
+static int add_one_sg(struct virtqueue *vq, void *addr, uint32_t size)
+{
+   struct scatterlist sg;
+
+   sg_init_one(, addr, size);
+   return virtqueue_add_inbuf(vq, , 1, vq, GFP_KERNEL);
+}
+
+static void send_balloon_page_sg(struct virtio_balloon *vb,
+struct virtqueue *vq,
+void *addr,
+uint32_t size)
+{
+   unsigned int len;
+   int ret;
+
+   do {
+   ret = add_one_sg(vq, addr, size);
+   virtqueue_kick(vq);
+   wait_event(vb->acked, virtqueue_get_buf(vq, ));
+   /*
+* It is uncommon to see the vq is full, because the sg is sent
+* one by one and the device is able to handle it in time. But
+* if that happens, we go back to retry after an entry gets
+* released.
+*/
+   } while (unlikely(ret == -ENOSPC));
+}
+
+/*
+ * Send balloon pages in sgs to host. The balloon pages are recorded in the
+ * page xbitmap. Each bit in the bitmap corresponds to a page of PAGE_SIZE.
+ * The page xbitmap is searched for continuous "1" bits, which correspond
+ * to continuous pages, to chunk into sgs.
+ *
+ * @page_xb_start and @page_xb_end form the range of bits in the xbitmap that
+ * need to be searched.
+ */
+static void tell_host_sgs(struct virtio_balloon *vb,
+ struct virtqueue *vq,
+ unsigned long page_xb_start,
+ unsigned long page_xb_end)
+{
+   unsigned long sg_pfn_start, sg_pfn_end;
+   void *sg_addr;
+   uint32_t sg_len, sg_max_len = round_down(UINT_MAX, PAGE_SIZE);
+
+   sg_pfn_start = page_xb_start;
+   while (sg_pfn_start < page_xb_end) {
+   sg_pfn_start = xb_find_next_bit(>page_xb, sg_pfn_start,
+   page_xb_end, 1);
+   if (sg_pfn_start == page_xb_end + 1)
+   break;
+   sg_pfn_end = xb_find_next_bit(>page_xb, sg_pfn_start + 1,
+ page_xb_end, 0);
+   sg_addr = (void *)pfn_to_kaddr(sg_pfn_start);
+   sg_len = (sg_pfn_end - sg_pfn_start) << PAGE_SHIFT;
+   while (sg_len > sg_max_len) {
+   send_balloon_page_sg(vb, vq, sg_addr, sg_max_len);
+   sg_addr += sg_max_len;
+   sg_len -= sg_max_len;
+   }
+   send_balloon_page_sg(vb, vq, sg_addr, sg_len);
+   xb_zero(>page_xb, sg_pfn_start, sg_pfn_end);
+