[PATCH] KVM: MMU: Introduce single thread to zap collapsible sptes

[Wanpeng Li]

From: Wanpeng Li 

Last year guys from huawei reported that the call of 
memory_global_dirty_log_start/stop() 
takes 13s for 4T memory and cause guest freeze too long which increases the 
unacceptable 
migration downtime. [1] [2]

Guangrong pointed out:

| collapsible_sptes zaps 4k mappings to make memory-read happy, it is not
| required by the semanteme of KVM_SET_USER_MEMORY_REGION and it is not
| urgent for vCPU's running, it could be done in a separate thread and use
| lock-break technology.

[1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05249.html
[2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg449994.html

Several TB memory guest is common now after NVDIMM is deployed in cloud 
environment.
This patch utilizes worker thread to zap collapsible sptes in order to lazy 
collapse 
small sptes into large sptes during roll-back after live migration fails.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/include/asm/kvm_host.h |  3 +++
 arch/x86/kvm/mmu.c  | 37 -
 arch/x86/kvm/x86.c  |  4 
 3 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index fbda5a9..dde32f9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -892,6 +892,8 @@ struct kvm_arch {
u64 master_cycle_now;
struct delayed_work kvmclock_update_work;
struct delayed_work kvmclock_sync_work;
+   struct delayed_work kvm_mmu_zap_collapsible_sptes_work;
+   bool zap_in_progress;
 
struct kvm_xen_hvm_config xen_hvm_config;
 
@@ -1247,6 +1249,7 @@ void kvm_mmu_zap_all(struct kvm *kvm);
 void kvm_mmu_invalidate_mmio_sptes(struct kvm *kvm, struct kvm_memslots 
*slots);
 unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm);
 void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned int kvm_nr_mmu_pages);
+void zap_collapsible_sptes_fn(struct work_struct *work);
 
 int load_pdptrs(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, unsigned long cr3);
 bool pdptrs_changed(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7c03c0f..fe87dd3 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5679,14 +5679,41 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm 
*kvm,
return need_tlb_flush;
 }
 
+void zap_collapsible_sptes_fn(struct work_struct *work)
+{
+   struct kvm_memory_slot *memslot;
+   struct kvm_memslots *slots;
+   struct delayed_work *dwork = to_delayed_work(work);
+   struct kvm_arch *ka = container_of(dwork, struct kvm_arch,
+  kvm_mmu_zap_collapsible_sptes_work);
+   struct kvm *kvm = container_of(ka, struct kvm, arch);
+   int i;
+
+   mutex_lock(>slots_lock);
+   for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
+   spin_lock(>mmu_lock);
+   slots = __kvm_memslots(kvm, i);
+   kvm_for_each_memslot(memslot, slots) {
+   slot_handle_leaf(kvm, (struct kvm_memory_slot *)memslot,
+   kvm_mmu_zap_collapsible_spte, true);
+   if (need_resched() || spin_needbreak(>mmu_lock))
+   cond_resched_lock(>mmu_lock);
+   }
+   spin_unlock(>mmu_lock);
+   }
+   kvm->arch.zap_in_progress = false;
+   mutex_unlock(>slots_lock);
+}
+
+#define KVM_MMU_ZAP_DELAYED (60 * HZ)
 void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
   const struct kvm_memory_slot *memslot)
 {
-   /* FIXME: const-ify all uses of struct kvm_memory_slot.  */
-   spin_lock(>mmu_lock);
-   slot_handle_leaf(kvm, (struct kvm_memory_slot *)memslot,
-kvm_mmu_zap_collapsible_spte, true);
-   spin_unlock(>mmu_lock);
+   if (!kvm->arch.zap_in_progress) {
+   kvm->arch.zap_in_progress = true;
+   
schedule_delayed_work(>arch.kvm_mmu_zap_collapsible_sptes_work,
+   KVM_MMU_ZAP_DELAYED);
+   }
 }
 
 void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d029377..c2af289 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9019,6 +9019,9 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
 
INIT_DELAYED_WORK(>arch.kvmclock_update_work, kvmclock_update_fn);
INIT_DELAYED_WORK(>arch.kvmclock_sync_work, kvmclock_sync_fn);
+   INIT_DELAYED_WORK(>arch.kvm_mmu_zap_collapsible_sptes_work,
+   zap_collapsible_sptes_fn);
+   kvm->arch.zap_in_progress = false;
 
kvm_hv_init_vm(kvm);
kvm_page_track_init(kvm);
@@ -9064,6 +9067,7 @@ void kvm_arch_sync_events(struct kvm *kvm)
 {
cancel_delayed_work_sync(>arch.kvmclock_sync_work);
cancel_delayed_work_sync(>arch.kvmclock_update_work);
+   

[PATCH] KVM: MMU: Introduce single thread to zap collapsible sptes

[Wanpeng Li]

From: Wanpeng Li 

Last year guys from huawei reported that the call of 
memory_global_dirty_log_start/stop() 
takes 13s for 4T memory and cause guest freeze too long which increases the 
unacceptable 
migration downtime. [1] [2]

Guangrong pointed out:

| collapsible_sptes zaps 4k mappings to make memory-read happy, it is not
| required by the semanteme of KVM_SET_USER_MEMORY_REGION and it is not
| urgent for vCPU's running, it could be done in a separate thread and use
| lock-break technology.

[1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05249.html
[2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg449994.html

Several TB memory guest is common now after NVDIMM is deployed in cloud 
environment.
This patch utilizes worker thread to zap collapsible sptes in order to lazy 
collapse 
small sptes into large sptes during roll-back after live migration fails.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/include/asm/kvm_host.h |  3 +++
 arch/x86/kvm/mmu.c  | 37 -
 arch/x86/kvm/x86.c  |  4 
 3 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index fbda5a9..dde32f9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -892,6 +892,8 @@ struct kvm_arch {
u64 master_cycle_now;
struct delayed_work kvmclock_update_work;
struct delayed_work kvmclock_sync_work;
+   struct delayed_work kvm_mmu_zap_collapsible_sptes_work;
+   bool zap_in_progress;
 
struct kvm_xen_hvm_config xen_hvm_config;
 
@@ -1247,6 +1249,7 @@ void kvm_mmu_zap_all(struct kvm *kvm);
 void kvm_mmu_invalidate_mmio_sptes(struct kvm *kvm, struct kvm_memslots 
*slots);
 unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm);
 void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned int kvm_nr_mmu_pages);
+void zap_collapsible_sptes_fn(struct work_struct *work);
 
 int load_pdptrs(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, unsigned long cr3);
 bool pdptrs_changed(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7c03c0f..fe87dd3 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5679,14 +5679,41 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm 
*kvm,
return need_tlb_flush;
 }
 
+void zap_collapsible_sptes_fn(struct work_struct *work)
+{
+   struct kvm_memory_slot *memslot;
+   struct kvm_memslots *slots;
+   struct delayed_work *dwork = to_delayed_work(work);
+   struct kvm_arch *ka = container_of(dwork, struct kvm_arch,
+  kvm_mmu_zap_collapsible_sptes_work);
+   struct kvm *kvm = container_of(ka, struct kvm, arch);
+   int i;
+
+   mutex_lock(>slots_lock);
+   for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
+   spin_lock(>mmu_lock);
+   slots = __kvm_memslots(kvm, i);
+   kvm_for_each_memslot(memslot, slots) {
+   slot_handle_leaf(kvm, (struct kvm_memory_slot *)memslot,
+   kvm_mmu_zap_collapsible_spte, true);
+   if (need_resched() || spin_needbreak(>mmu_lock))
+   cond_resched_lock(>mmu_lock);
+   }
+   spin_unlock(>mmu_lock);
+   }
+   kvm->arch.zap_in_progress = false;
+   mutex_unlock(>slots_lock);
+}
+
+#define KVM_MMU_ZAP_DELAYED (60 * HZ)
 void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
   const struct kvm_memory_slot *memslot)
 {
-   /* FIXME: const-ify all uses of struct kvm_memory_slot.  */
-   spin_lock(>mmu_lock);
-   slot_handle_leaf(kvm, (struct kvm_memory_slot *)memslot,
-kvm_mmu_zap_collapsible_spte, true);
-   spin_unlock(>mmu_lock);
+   if (!kvm->arch.zap_in_progress) {
+   kvm->arch.zap_in_progress = true;
+   
schedule_delayed_work(>arch.kvm_mmu_zap_collapsible_sptes_work,
+   KVM_MMU_ZAP_DELAYED);
+   }
 }
 
 void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d029377..c2af289 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9019,6 +9019,9 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
 
INIT_DELAYED_WORK(>arch.kvmclock_update_work, kvmclock_update_fn);
INIT_DELAYED_WORK(>arch.kvmclock_sync_work, kvmclock_sync_fn);
+   INIT_DELAYED_WORK(>arch.kvm_mmu_zap_collapsible_sptes_work,
+   zap_collapsible_sptes_fn);
+   kvm->arch.zap_in_progress = false;
 
kvm_hv_init_vm(kvm);
kvm_page_track_init(kvm);
@@ -9064,6 +9067,7 @@ void kvm_arch_sync_events(struct kvm *kvm)
 {
cancel_delayed_work_sync(>arch.kvmclock_sync_work);
cancel_delayed_work_sync(>arch.kvmclock_update_work);
+   

Re: [PATCH V3 rebase] mmc: sdhci: fix the timeout check window for clock and reset

[Ulf Hansson]

On Thu, 6 Dec 2018 at 00:33, Du, Alek  wrote:
>
> From a081e783383adf1179c71bc37b4e199d087af643 Mon Sep 17 00:00:00 2001
> From: Alek Du 
> Date: Fri, 30 Nov 2018 14:02:28 +0800
> Subject: [PATCH] mmc: sdhci: fix the timeout check window for clock and reset
>
> We observed some premature timeouts on a virtualization platform, the log
> is like this:
>
> case 1:
> [159525.255629] mmc1: Internal clock never stabilised.
> [159525.255818] mmc1: sdhci:  SDHCI REGISTER DUMP ===
> [159525.256049] mmc1: sdhci: Sys addr:  0x | Version:  0x1002
> ...
> [159525.257205] mmc1: sdhci: Wake-up:   0x | Clock:0xfa03
> From the clock control register dump, we are pretty sure the clock was
> stablized.
>
> case 2:
> [  914.550127] mmc1: Reset 0x2 never completed.
> [  914.550321] mmc1: sdhci:  SDHCI REGISTER DUMP ===
> [  914.550608] mmc1: sdhci: Sys addr:  0x0010 | Version:  0x1002
>
> After checking the sdhci code, we found the timeout check actually has a
> little window that the CPU can be scheduled out and when it comes back,
> the original time set or check is not valid.
>
> Fixes: 5a436cc0af62 ("mmc: sdhci: Optimize delay loops")
> Cc: sta...@vger.kernel.org  # v4.12+
> Signed-off-by: Alek Du 

I am still not able to apply this, however the reason is not that a
rebase is needed.

Instead it seems like the patch is malformed, exactly why I don't
know. I am using patchwork to fetch the patch, but I even tried
fetching it directly via my gmail client, no luck. In both case it
can't be applied and checkpatch is also complaining.

Could you check at your side and see what can be wrong? If there is
too much hazzle I can manually fixup the patch next week, as one time
thing.

Kind regards
Uffe

> ---
>  drivers/mmc/host/sdhci.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 99bdae53fa2e..451b08a818a9 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -216,8 +216,12 @@ void sdhci_reset(struct sdhci_host *host, u8 mask)
> timeout = ktime_add_ms(ktime_get(), 100);
>
> /* hw clears the bit when it's done */
> -   while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) {
> -   if (ktime_after(ktime_get(), timeout)) {
> +   while (1) {
> +   bool timedout = ktime_after(ktime_get(), timeout);
> +
> +   if (!(sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask))
> +   break;
> +   if (timedout) {
> pr_err("%s: Reset 0x%x never completed.\n",
> mmc_hostname(host->mmc), (int)mask);
> sdhci_dumpregs(host);
> @@ -1608,9 +1612,13 @@ void sdhci_enable_clk(struct sdhci_host *host, u16 clk)
>
> /* Wait max 20 ms */
> timeout = ktime_add_ms(ktime_get(), 20);
> -   while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
> -   & SDHCI_CLOCK_INT_STABLE)) {
> -   if (ktime_after(ktime_get(), timeout)) {
> +   while (1) {
> +   bool timedout = ktime_after(ktime_get(), timeout);
> +
> +   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> +   if (clk & SDHCI_CLOCK_INT_STABLE)
> +   break;
> +   if (timedout) {
> pr_err("%s: Internal clock never stabilised.\n",
>mmc_hostname(host->mmc));
> sdhci_dumpregs(host);
> --
> 2.17.1

Re: [PATCH V3 rebase] mmc: sdhci: fix the timeout check window for clock and reset

[Ulf Hansson]

On Thu, 6 Dec 2018 at 00:33, Du, Alek  wrote:
>
> From a081e783383adf1179c71bc37b4e199d087af643 Mon Sep 17 00:00:00 2001
> From: Alek Du 
> Date: Fri, 30 Nov 2018 14:02:28 +0800
> Subject: [PATCH] mmc: sdhci: fix the timeout check window for clock and reset
>
> We observed some premature timeouts on a virtualization platform, the log
> is like this:
>
> case 1:
> [159525.255629] mmc1: Internal clock never stabilised.
> [159525.255818] mmc1: sdhci:  SDHCI REGISTER DUMP ===
> [159525.256049] mmc1: sdhci: Sys addr:  0x | Version:  0x1002
> ...
> [159525.257205] mmc1: sdhci: Wake-up:   0x | Clock:0xfa03
> From the clock control register dump, we are pretty sure the clock was
> stablized.
>
> case 2:
> [  914.550127] mmc1: Reset 0x2 never completed.
> [  914.550321] mmc1: sdhci:  SDHCI REGISTER DUMP ===
> [  914.550608] mmc1: sdhci: Sys addr:  0x0010 | Version:  0x1002
>
> After checking the sdhci code, we found the timeout check actually has a
> little window that the CPU can be scheduled out and when it comes back,
> the original time set or check is not valid.
>
> Fixes: 5a436cc0af62 ("mmc: sdhci: Optimize delay loops")
> Cc: sta...@vger.kernel.org  # v4.12+
> Signed-off-by: Alek Du 

I am still not able to apply this, however the reason is not that a
rebase is needed.

Instead it seems like the patch is malformed, exactly why I don't
know. I am using patchwork to fetch the patch, but I even tried
fetching it directly via my gmail client, no luck. In both case it
can't be applied and checkpatch is also complaining.

Could you check at your side and see what can be wrong? If there is
too much hazzle I can manually fixup the patch next week, as one time
thing.

Kind regards
Uffe

> ---
>  drivers/mmc/host/sdhci.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 99bdae53fa2e..451b08a818a9 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -216,8 +216,12 @@ void sdhci_reset(struct sdhci_host *host, u8 mask)
> timeout = ktime_add_ms(ktime_get(), 100);
>
> /* hw clears the bit when it's done */
> -   while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) {
> -   if (ktime_after(ktime_get(), timeout)) {
> +   while (1) {
> +   bool timedout = ktime_after(ktime_get(), timeout);
> +
> +   if (!(sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask))
> +   break;
> +   if (timedout) {
> pr_err("%s: Reset 0x%x never completed.\n",
> mmc_hostname(host->mmc), (int)mask);
> sdhci_dumpregs(host);
> @@ -1608,9 +1612,13 @@ void sdhci_enable_clk(struct sdhci_host *host, u16 clk)
>
> /* Wait max 20 ms */
> timeout = ktime_add_ms(ktime_get(), 20);
> -   while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
> -   & SDHCI_CLOCK_INT_STABLE)) {
> -   if (ktime_after(ktime_get(), timeout)) {
> +   while (1) {
> +   bool timedout = ktime_after(ktime_get(), timeout);
> +
> +   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> +   if (clk & SDHCI_CLOCK_INT_STABLE)
> +   break;
> +   if (timedout) {
> pr_err("%s: Internal clock never stabilised.\n",
>mmc_hostname(host->mmc));
> sdhci_dumpregs(host);
> --
> 2.17.1

Re: [PATCH v14 00/11] livepatch: Atomic replace feature

[Petr Mladek]

On Wed 2018-12-05 15:49:14, Joe Lawrence wrote:
> On 11/29/2018 04:44 AM, Petr Mladek wrote:
> > The atomic replace allows to create cumulative patches. They
> > are useful when you maintain many livepatches and want to remove
> > one that is lower on the stack. In addition it is very useful when
> > more patches touch the same function and there are dependencies
> > between them.
> > 
> > Changes against v13:
> > 
> >   + Add custom kobj_alive flag to reliably handle kobj state. [Miroslav]
> > 
> 
> Aside: I don't suppose that this could ever be folded into the kobject
> code/data structure itself?  This seems like a common problem that
> kobj-users will need to solve like this.

I am afraid that it does not have much chance to get solved in
kobject. They are not designed to be used in static objets and
there is pushback against this usecase.


> I don't have many code comments as the changes appear to safely and
> correctly do what the say.  (We are at v14 after all :)  I mainly
> compared the text and comments to the implementation and noted typos
> (marked by substitution s/old/new) and awkward wordings (marked by
> "re-wording suggestion").  That said, I ack'd each patch as I wouldn't
> want these to hold up the patchset.

Thanks a lot both you and Miroslav for the review.

I'll give it some more days before I prepare v15. I wonder if Josh
could find some cycle to look at it at least from the top level.

Best Regards,
Petr

Re: [PATCH v14 00/11] livepatch: Atomic replace feature

[Petr Mladek]

On Wed 2018-12-05 15:49:14, Joe Lawrence wrote:
> On 11/29/2018 04:44 AM, Petr Mladek wrote:
> > The atomic replace allows to create cumulative patches. They
> > are useful when you maintain many livepatches and want to remove
> > one that is lower on the stack. In addition it is very useful when
> > more patches touch the same function and there are dependencies
> > between them.
> > 
> > Changes against v13:
> > 
> >   + Add custom kobj_alive flag to reliably handle kobj state. [Miroslav]
> > 
> 
> Aside: I don't suppose that this could ever be folded into the kobject
> code/data structure itself?  This seems like a common problem that
> kobj-users will need to solve like this.

I am afraid that it does not have much chance to get solved in
kobject. They are not designed to be used in static objets and
there is pushback against this usecase.


> I don't have many code comments as the changes appear to safely and
> correctly do what the say.  (We are at v14 after all :)  I mainly
> compared the text and comments to the implementation and noted typos
> (marked by substitution s/old/new) and awkward wordings (marked by
> "re-wording suggestion").  That said, I ack'd each patch as I wouldn't
> want these to hold up the patchset.

Thanks a lot both you and Miroslav for the review.

I'll give it some more days before I prepare v15. I wonder if Josh
could find some cycle to look at it at least from the top level.

Best Regards,
Petr

Re: [PATCH] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3

[Anand Moon]

Hi Krzysztof,

On Wed, 5 Dec 2018 at 21:49, Krzysztof Kozlowski  wrote:
>
> On Wed, 5 Dec 2018 at 17:11, Anand Moon  wrote:
> >
> > Hi Krzysztof,
> >
> > Thanks for your review.
> > .
> > On Wed, 5 Dec 2018 at 19:36, Krzysztof Kozlowski  wrote:
> > >
> > > On Tue, 4 Dec 2018 at 20:40, Anand Moon  wrote:
> > > >
> > > > Add suspend-to-mem node to regulator core to be enabled or disabled
> > > > during system suspend and also support changing the regulator operating
> > > > mode during runtime and when the system enter sleep mode.
> > > >
> > > > Signed-off-by: Anand Moon 
> > > > ---
> > > > Tested on Odroid U3+
> > > > ---
> > > >  .../boot/dts/exynos4412-odroid-common.dtsi| 72 +++
> > > >  1 file changed, 72 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > index 2caa3132f34e..837713a2ec3b 100644
> > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > @@ -285,6 +285,9 @@
> > > > regulator-min-microvolt = <180>;
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > >
> > > Driver does not support suspend_enable so this will be noop. We could
> > > add this for DT-correctness (and full description of HW) but then I
> > > need explanation why this regulator has to stay on during suspend.
> > >
> >
> > Well I tried to study the suspend/resume feature from
> > *arch/arm/boot/dts/exynos4412-midas.dtsi*
> > and them I tried to apply the same with this on Odroid-U3 boards and
> > test these changes.
>
> Midas DTSI clearly has bugs then.
>
> >
> > > > };
> > > >
> > > > ldo3_reg: LDO3 {
> > > > @@ -292,6 +295,9 @@
> > > > regulator-min-microvolt = <180>;
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-off-in-suspend;
> > > > +   };
> > >
> > > The same but with suspend_disable.
> > >
> > > I am not saying that these are wrong but I would be happy to see
> > > explanations why you chosen these particular properties.
> > >
> >
> > Well I was not aware on the regulator-always-on cannot be set to off
> > in suspend mode.
> > Will drop this in the future patch where regulator-always-on; is set.
> >
> > > > };
> > > >
> > > > ldo4_reg: LDO4 {
> > > > @@ -299,6 +305,9 @@
> > > > regulator-min-microvolt = <280>;
> > > > regulator-max-microvolt = <280>;
> > > > regulator-boot-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > > > };
> > > >
> > > > ldo5_reg: LDO5 {
> > > > @@ -307,6 +316,9 @@
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > regulator-boot-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > > > };
> > > >
> > > > ldo6_reg: LDO6 {
> > > > @@ -314,6 +326,9 @@
> > > > regulator-min-microvolt = <100>;
> > > > regulator-max-microvolt = <100>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > > > };
> > > >
> > > > ldo7_reg: LDO7 {
> > > > @@ -321,18 +336,27 @@
> > > > regulator-min-microvolt = <100>;
> > > > regulator-max-microvolt = <100>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > > > };
> > > >
> > > > ldo8_reg: LDO8 {
> > > > 

Re: [PATCH] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3

[Anand Moon]

Hi Krzysztof,

On Wed, 5 Dec 2018 at 21:49, Krzysztof Kozlowski  wrote:
>
> On Wed, 5 Dec 2018 at 17:11, Anand Moon  wrote:
> >
> > Hi Krzysztof,
> >
> > Thanks for your review.
> > .
> > On Wed, 5 Dec 2018 at 19:36, Krzysztof Kozlowski  wrote:
> > >
> > > On Tue, 4 Dec 2018 at 20:40, Anand Moon  wrote:
> > > >
> > > > Add suspend-to-mem node to regulator core to be enabled or disabled
> > > > during system suspend and also support changing the regulator operating
> > > > mode during runtime and when the system enter sleep mode.
> > > >
> > > > Signed-off-by: Anand Moon 
> > > > ---
> > > > Tested on Odroid U3+
> > > > ---
> > > >  .../boot/dts/exynos4412-odroid-common.dtsi| 72 +++
> > > >  1 file changed, 72 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > index 2caa3132f34e..837713a2ec3b 100644
> > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > @@ -285,6 +285,9 @@
> > > > regulator-min-microvolt = <180>;
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > >
> > > Driver does not support suspend_enable so this will be noop. We could
> > > add this for DT-correctness (and full description of HW) but then I
> > > need explanation why this regulator has to stay on during suspend.
> > >
> >
> > Well I tried to study the suspend/resume feature from
> > *arch/arm/boot/dts/exynos4412-midas.dtsi*
> > and them I tried to apply the same with this on Odroid-U3 boards and
> > test these changes.
>
> Midas DTSI clearly has bugs then.
>
> >
> > > > };
> > > >
> > > > ldo3_reg: LDO3 {
> > > > @@ -292,6 +295,9 @@
> > > > regulator-min-microvolt = <180>;
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-off-in-suspend;
> > > > +   };
> > >
> > > The same but with suspend_disable.
> > >
> > > I am not saying that these are wrong but I would be happy to see
> > > explanations why you chosen these particular properties.
> > >
> >
> > Well I was not aware on the regulator-always-on cannot be set to off
> > in suspend mode.
> > Will drop this in the future patch where regulator-always-on; is set.
> >
> > > > };
> > > >
> > > > ldo4_reg: LDO4 {
> > > > @@ -299,6 +305,9 @@
> > > > regulator-min-microvolt = <280>;
> > > > regulator-max-microvolt = <280>;
> > > > regulator-boot-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > > > };
> > > >
> > > > ldo5_reg: LDO5 {
> > > > @@ -307,6 +316,9 @@
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > regulator-boot-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > > > };
> > > >
> > > > ldo6_reg: LDO6 {
> > > > @@ -314,6 +326,9 @@
> > > > regulator-min-microvolt = <100>;
> > > > regulator-max-microvolt = <100>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > > > };
> > > >
> > > > ldo7_reg: LDO7 {
> > > > @@ -321,18 +336,27 @@
> > > > regulator-min-microvolt = <100>;
> > > > regulator-max-microvolt = <100>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > > > };
> > > >
> > > > ldo8_reg: LDO8 {
> > > > 

New RED Racing Parts: 10% / 15% off and free shipping

[RED Racing Parts (Info)]

Dear Rider,

RED Racing Parts offers the new full line of carbon fiber parts for your 
motorbike.

For road / offroad motorcycles, visit our website on 
https://www.redracingparts.com/english/motorbikesmotorcycles/productsandcomponents/general/intro/carbonfibrefiber.php

For trial motorcycles, visit our website on 
https://www.redracingparts.com/english/motorbikesmotorcycles/productsandcomponents/general/intro/2mCarbonFiberParts.php

Free shipping and 10% OFF (15% OFF paying with Bitcoin) for today only.


RED Racing Parts Staff




If you found this email useful, please forward it on to your friends.

To unsubscribe our newsletters click here
https://www.redracingparts.com/news/u.php?l=e=cvaidqzxnfcihwm8b9u2linux-ker...@vger.kernel.org

New RED Racing Parts: 10% / 15% off and free shipping

[RED Racing Parts (Info)]

Dear Rider,

RED Racing Parts offers the new full line of carbon fiber parts for your 
motorbike.

For road / offroad motorcycles, visit our website on 
https://www.redracingparts.com/english/motorbikesmotorcycles/productsandcomponents/general/intro/carbonfibrefiber.php

For trial motorcycles, visit our website on 
https://www.redracingparts.com/english/motorbikesmotorcycles/productsandcomponents/general/intro/2mCarbonFiberParts.php

Free shipping and 10% OFF (15% OFF paying with Bitcoin) for today only.


RED Racing Parts Staff




If you found this email useful, please forward it on to your friends.

To unsubscribe our newsletters click here
https://www.redracingparts.com/news/u.php?l=e=cvaidqzxnfcihwm8b9u2linux-ker...@vger.kernel.org

Re: [PATCH V2 1/4] ARM: dts: imx6qdl-sabresd: Move regulators outside of "simple-bus"

[Shawn Guo]

On Thu, Dec 06, 2018 at 01:42:30AM +, Anson Huang wrote:
> From: Fabio Estevam 
> 
> It is not recommended to place regulators inside "simple-bus", so move
> them out to make it cleaner the addition of new regulators.
> 
> Signed-off-by: Fabio Estevam 

Applied all, thanks.

Re: [PATCH V2 1/4] ARM: dts: imx6qdl-sabresd: Move regulators outside of "simple-bus"

[Shawn Guo]

On Thu, Dec 06, 2018 at 01:42:30AM +, Anson Huang wrote:
> From: Fabio Estevam 
> 
> It is not recommended to place regulators inside "simple-bus", so move
> them out to make it cleaner the addition of new regulators.
> 
> Signed-off-by: Fabio Estevam 

Applied all, thanks.

[PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS

[Andrey Smirnov]

Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
produces a system where built-in PCIE bridge (16c3:abcd) isn't bound
to pcieport driver. This, in turn, results in a PCIE bus that is
capable of enumerating attached PCIE device, but lacks functional
interrupt support.

Signed-off-by: Andrey Smirnov 
---

Assuming this is a reasonable dependency, shold this be done to more
than just i.MX6 driver?

 drivers/pci/controller/dwc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 2b139acccf32..44ededbeab85 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -92,6 +92,7 @@ config PCI_IMX6
bool "Freescale i.MX6 PCIe controller"
depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
depends on PCI_MSI_IRQ_DOMAIN
+   depends on PCIEPORTBUS
select PCIE_DW_HOST
 
 config PCIE_SPEAR13XX
-- 
2.19.1

[PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS

[Andrey Smirnov]

Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
produces a system where built-in PCIE bridge (16c3:abcd) isn't bound
to pcieport driver. This, in turn, results in a PCIE bus that is
capable of enumerating attached PCIE device, but lacks functional
interrupt support.

Signed-off-by: Andrey Smirnov 
---

Assuming this is a reasonable dependency, shold this be done to more
than just i.MX6 driver?

 drivers/pci/controller/dwc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 2b139acccf32..44ededbeab85 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -92,6 +92,7 @@ config PCI_IMX6
bool "Freescale i.MX6 PCIe controller"
depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
depends on PCI_MSI_IRQ_DOMAIN
+   depends on PCIEPORTBUS
select PCIE_DW_HOST
 
 config PCIE_SPEAR13XX
-- 
2.19.1

Re: [PATCH 04/14] dt-bindings: timer: Add Milbeaut M10V timer description

[Sugaya, Taichi]

Hi,

Thank you for your comments.

On 2018/12/05 8:03, Rob Herring wrote:

On Mon, Nov 19, 2018 at 10:01:09AM +0900, Sugaya Taichi wrote:

Add DT bindings document for Milbeaut M10V timer.

Signed-off-by: Sugaya Taichi 
---
  .../bindings/timer/socionext,milbeaut-timer.txt | 17 +
  1 file changed, 17 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt

diff --git 
a/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt 
b/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
new file mode 100644
index 000..ddb1b31
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
@@ -0,0 +1,17 @@
+Milbeaut SoCs Timer Controller
+
+Required properties:
+
+- compatible : should be "socionext,milbeaut-m10v-timer"
+- reg : Specifies base physical address and size of the registers.


How many register ranges? Looks like 2.


Yes, has two ranges.
So add the description about it.




+- interrupts : The interrupt of the first timer
+- clocks: should be "rclk"
+
+Example:
+
+timer {


timer@1e50


Okay.

Thanks
Sugaya Taichi




+   compatible = "socionext,milbeaut-m10v-timer";
+   reg = <0x1e50 0x10>, <0x1e60 0x10>;
+   interrupts = <0 91 4>;
+   clocks = <>;
+};
--
1.9.1

Re: [PATCH 04/14] dt-bindings: timer: Add Milbeaut M10V timer description

[Sugaya, Taichi]

Hi,

Thank you for your comments.

On 2018/12/05 8:03, Rob Herring wrote:

On Mon, Nov 19, 2018 at 10:01:09AM +0900, Sugaya Taichi wrote:

Add DT bindings document for Milbeaut M10V timer.

Signed-off-by: Sugaya Taichi 
---
  .../bindings/timer/socionext,milbeaut-timer.txt | 17 +
  1 file changed, 17 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt

diff --git 
a/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt 
b/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
new file mode 100644
index 000..ddb1b31
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
@@ -0,0 +1,17 @@
+Milbeaut SoCs Timer Controller
+
+Required properties:
+
+- compatible : should be "socionext,milbeaut-m10v-timer"
+- reg : Specifies base physical address and size of the registers.


How many register ranges? Looks like 2.


Yes, has two ranges.
So add the description about it.




+- interrupts : The interrupt of the first timer
+- clocks: should be "rclk"
+
+Example:
+
+timer {


timer@1e50


Okay.

Thanks
Sugaya Taichi




+   compatible = "socionext,milbeaut-m10v-timer";
+   reg = <0x1e50 0x10>, <0x1e60 0x10>;
+   interrupts = <0 91 4>;
+   clocks = <>;
+};
--
1.9.1

Re: [PATCH v2] ARM: dts: vf610-zii-scu4-aib: Add HI8435 support

[Shawn Guo]

On Wed, Dec 05, 2018 at 09:19:35AM -0200, Fabio Estevam wrote:
> On the vf610-zii-scu4-aib board there is a hi8435 (32-channel
> discrete-to-digital SPI sensor device) in the DSPI0 bus.
> 
> Add support for it.
> 
> Signed-off-by: Fabio Estevam 
> Reviewed-by: Chris Healy 

Applied, thanks.

Re: [PATCH v2] ARM: dts: vf610-zii-scu4-aib: Add HI8435 support

[Shawn Guo]

On Wed, Dec 05, 2018 at 09:19:35AM -0200, Fabio Estevam wrote:
> On the vf610-zii-scu4-aib board there is a hi8435 (32-channel
> discrete-to-digital SPI sensor device) in the DSPI0 bus.
> 
> Add support for it.
> 
> Signed-off-by: Fabio Estevam 
> Reviewed-by: Chris Healy 

Applied, thanks.

Re: [PATCH V2] ARM: dts: imx6qdl-sabresd: add egalax touch screen support on i2c2 bus

[Shawn Guo]

On Wed, Dec 05, 2018 at 01:14:25AM +, Anson Huang wrote:
> Add egalax touch screen support on i2c2 bus, it is connected
> to LVDS0, while the existing one on i2c3 bus is connected to
> LVDS1.
> 
> Signed-off-by: Anson Huang 

Applied, thanks.

Re: [PATCH V2] ARM: dts: imx6qdl-sabresd: add egalax touch screen support on i2c2 bus

[Shawn Guo]

On Wed, Dec 05, 2018 at 01:14:25AM +, Anson Huang wrote:
> Add egalax touch screen support on i2c2 bus, it is connected
> to LVDS0, while the existing one on i2c3 bus is connected to
> LVDS1.
> 
> Signed-off-by: Anson Huang 

Applied, thanks.

[PATCH v2 1/3] PCI: imx: No-op imx6_setup_phy_mpll() on i.MX7D

[Andrey Smirnov]

PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
so none of the code in current implementation of imx6_setup_phy_mpll()
is applicable.

Cc: bhelg...@google.com
Cc: Fabio Estevam 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Tested-by: Trent Piepho 
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 2cbef2d7c207..c140f7987598 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -525,6 +525,9 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
int mult, div;
u32 val;
 
+   if (imx6_pcie->variant == IMX7D)
+   return 0;
+
switch (phy_rate) {
case 12500:
/*
-- 
2.19.1

[PATCH v2 3/3] PCI: imx: Add support for i.MX8MQ

[Andrey Smirnov]

Add code needed to support i.MX8MQ variant.

Cc: bhelg...@google.com
Cc: Fabio Estevam 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 .../bindings/pci/fsl,imx6q-pcie.txt   |  6 +-
 drivers/pci/controller/dwc/Kconfig|  2 +-
 drivers/pci/controller/dwc/pci-imx6.c | 85 +--
 3 files changed, 86 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt 
b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
index f37494d5a7be..40b46d11e7e7 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -9,6 +9,7 @@ Required properties:
- "fsl,imx6sx-pcie",
- "fsl,imx6qp-pcie"
- "fsl,imx7d-pcie"
+   - "fsl,imx8mq-pcie"
 - reg: base address and length of the PCIe controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
@@ -43,7 +44,7 @@ Additional required properties for imx6sx-pcie:
- "pcie_inbound_axi"
 - power-domains: Must be set to a phandle pointing to the PCIE_PHY power domain
 
-Additional required properties for imx7d-pcie:
+Additional required properties for imx7d-pcie and imx8mq-pcie:
 - power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
 - resets: Must contain phandles to PCIe-related reset lines exposed by SRC
   IP block
@@ -52,6 +53,9 @@ Additional required properties for imx7d-pcie:
   - "apps"
   - "turnoff"
 
+Additional required properties for imx8mq-pcie:
+- fsl,controller-id: Logical ID of a given PCIE controller. PCIE1 is 0, PCIE2 
is 1;
+
 Example:
 
pcie@0100 {
diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 91b0194240a5..2b139acccf32 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -90,7 +90,7 @@ config PCI_EXYNOS
 
 config PCI_IMX6
bool "Freescale i.MX6 PCIe controller"
-   depends on SOC_IMX6Q || (ARM && COMPILE_TEST)
+   depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
depends on PCI_MSI_IRQ_DOMAIN
select PCIE_DW_HOST
 
diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 3c3002861d25..326f71698ac2 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -8,6 +8,7 @@
  * Author: Sean Cross 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,11 @@
 
 #include "pcie-designware.h"
 
+#define IMX8MQ_GPR_PCIE_REF_USE_PADBIT(9)
+#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_ENBIT(10)
+#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE   BIT(11)
+#define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPEGENMASK(11, 8)
+
 #define to_imx6_pcie(x)dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -37,6 +43,7 @@ enum imx6_pcie_variants {
IMX6SX,
IMX6QP,
IMX7D,
+   IMX8MQ,
 };
 
 struct imx6_pcie {
@@ -48,6 +55,7 @@ struct imx6_pcie {
struct clk  *pcie_inbound_axi;
struct clk  *pcie;
struct regmap   *iomuxc_gpr;
+   u32 controller_id;
struct reset_control*pciephy_reset;
struct reset_control*apps_reset;
struct reset_control*turnoff_reset;
@@ -245,7 +253,8 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
 {
u32 tmp;
 
-   if (imx6_pcie->variant == IMX7D)
+   if (imx6_pcie->variant == IMX7D ||
+   imx6_pcie->variant == IMX8MQ)
return;
 
pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, );
@@ -261,6 +270,7 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
pcie_phy_write(imx6_pcie, PHY_RX_OVRD_IN_LO, tmp);
 }
 
+#ifdef CONFIG_ARM
 /*  Added for PCI abort handling */
 static int imx6q_pcie_abort_handler(unsigned long addr,
unsigned int fsr, struct pt_regs *regs)
@@ -294,6 +304,7 @@ static int imx6q_pcie_abort_handler(unsigned long addr,
 
return 1;
 }
+#endif
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 {
@@ -301,6 +312,7 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie 
*imx6_pcie)
 
switch (imx6_pcie->variant) {
case IMX7D:
+   case IMX8MQ: /* FALLTHROUGH */
reset_control_assert(imx6_pcie->pciephy_reset);
reset_control_assert(imx6_pcie->apps_reset);
break;
@@ -339,6 +351,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie 
*imx6_pcie)
 {
struct dw_pcie *pci = imx6_pcie->pci;

[PATCH v2 2/3] PCI: imx: No-op imx6_pcie_reset_phy() on i.MX7D

[Andrey Smirnov]

PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
so none of the code in current implementation of imx6_pcie_reset_phy()
is applicable.

Cc: bhelg...@google.com
Cc: Fabio Estevam 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Tested-by: Trent Piepho 
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index c140f7987598..3c3002861d25 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -245,6 +245,9 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
 {
u32 tmp;
 
+   if (imx6_pcie->variant == IMX7D)
+   return;
+
pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, );
tmp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN |
PHY_RX_OVRD_IN_LO_RX_PLL_EN);
-- 
2.19.1

[PATCH v2 1/3] PCI: imx: No-op imx6_setup_phy_mpll() on i.MX7D

[Andrey Smirnov]

PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
so none of the code in current implementation of imx6_setup_phy_mpll()
is applicable.

Cc: bhelg...@google.com
Cc: Fabio Estevam 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Tested-by: Trent Piepho 
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 2cbef2d7c207..c140f7987598 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -525,6 +525,9 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
int mult, div;
u32 val;
 
+   if (imx6_pcie->variant == IMX7D)
+   return 0;
+
switch (phy_rate) {
case 12500:
/*
-- 
2.19.1

[PATCH v2 3/3] PCI: imx: Add support for i.MX8MQ

[Andrey Smirnov]

Add code needed to support i.MX8MQ variant.

Cc: bhelg...@google.com
Cc: Fabio Estevam 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 .../bindings/pci/fsl,imx6q-pcie.txt   |  6 +-
 drivers/pci/controller/dwc/Kconfig|  2 +-
 drivers/pci/controller/dwc/pci-imx6.c | 85 +--
 3 files changed, 86 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt 
b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
index f37494d5a7be..40b46d11e7e7 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -9,6 +9,7 @@ Required properties:
- "fsl,imx6sx-pcie",
- "fsl,imx6qp-pcie"
- "fsl,imx7d-pcie"
+   - "fsl,imx8mq-pcie"
 - reg: base address and length of the PCIe controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
@@ -43,7 +44,7 @@ Additional required properties for imx6sx-pcie:
- "pcie_inbound_axi"
 - power-domains: Must be set to a phandle pointing to the PCIE_PHY power domain
 
-Additional required properties for imx7d-pcie:
+Additional required properties for imx7d-pcie and imx8mq-pcie:
 - power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
 - resets: Must contain phandles to PCIe-related reset lines exposed by SRC
   IP block
@@ -52,6 +53,9 @@ Additional required properties for imx7d-pcie:
   - "apps"
   - "turnoff"
 
+Additional required properties for imx8mq-pcie:
+- fsl,controller-id: Logical ID of a given PCIE controller. PCIE1 is 0, PCIE2 
is 1;
+
 Example:
 
pcie@0100 {
diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 91b0194240a5..2b139acccf32 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -90,7 +90,7 @@ config PCI_EXYNOS
 
 config PCI_IMX6
bool "Freescale i.MX6 PCIe controller"
-   depends on SOC_IMX6Q || (ARM && COMPILE_TEST)
+   depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
depends on PCI_MSI_IRQ_DOMAIN
select PCIE_DW_HOST
 
diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 3c3002861d25..326f71698ac2 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -8,6 +8,7 @@
  * Author: Sean Cross 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,11 @@
 
 #include "pcie-designware.h"
 
+#define IMX8MQ_GPR_PCIE_REF_USE_PADBIT(9)
+#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_ENBIT(10)
+#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE   BIT(11)
+#define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPEGENMASK(11, 8)
+
 #define to_imx6_pcie(x)dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -37,6 +43,7 @@ enum imx6_pcie_variants {
IMX6SX,
IMX6QP,
IMX7D,
+   IMX8MQ,
 };
 
 struct imx6_pcie {
@@ -48,6 +55,7 @@ struct imx6_pcie {
struct clk  *pcie_inbound_axi;
struct clk  *pcie;
struct regmap   *iomuxc_gpr;
+   u32 controller_id;
struct reset_control*pciephy_reset;
struct reset_control*apps_reset;
struct reset_control*turnoff_reset;
@@ -245,7 +253,8 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
 {
u32 tmp;
 
-   if (imx6_pcie->variant == IMX7D)
+   if (imx6_pcie->variant == IMX7D ||
+   imx6_pcie->variant == IMX8MQ)
return;
 
pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, );
@@ -261,6 +270,7 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
pcie_phy_write(imx6_pcie, PHY_RX_OVRD_IN_LO, tmp);
 }
 
+#ifdef CONFIG_ARM
 /*  Added for PCI abort handling */
 static int imx6q_pcie_abort_handler(unsigned long addr,
unsigned int fsr, struct pt_regs *regs)
@@ -294,6 +304,7 @@ static int imx6q_pcie_abort_handler(unsigned long addr,
 
return 1;
 }
+#endif
 
 static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 {
@@ -301,6 +312,7 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie 
*imx6_pcie)
 
switch (imx6_pcie->variant) {
case IMX7D:
+   case IMX8MQ: /* FALLTHROUGH */
reset_control_assert(imx6_pcie->pciephy_reset);
reset_control_assert(imx6_pcie->apps_reset);
break;
@@ -339,6 +351,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie 
*imx6_pcie)
 {
struct dw_pcie *pci = imx6_pcie->pci;

[PATCH v2 2/3] PCI: imx: No-op imx6_pcie_reset_phy() on i.MX7D

[Andrey Smirnov]

PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
so none of the code in current implementation of imx6_pcie_reset_phy()
is applicable.

Cc: bhelg...@google.com
Cc: Fabio Estevam 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Tested-by: Trent Piepho 
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index c140f7987598..3c3002861d25 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -245,6 +245,9 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
 {
u32 tmp;
 
+   if (imx6_pcie->variant == IMX7D)
+   return;
+
pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, );
tmp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN |
PHY_RX_OVRD_IN_LO_RX_PLL_EN);
-- 
2.19.1

[PATCH v2 0/3] PCIE support for i.MX8MQ

[Andrey Smirnov]

Everyone:

This series contains changes I made in order to enable support of PCIE
IP block on i.MX8MQ SoCs (full tree can be found at [github-v2]).

NOTE: The last patch have a Kconfig symbol depenency on [imx8mq-kconfig].

Changes since [v1]:

 - Driver changed to use single "fsl,controller-id" property to
   distinguish between two intances of PCIE IP block

 - All code pertaining to L1SS was dropped to simplify the patch

 - Documented additions to DT bindings

Feedback is welcome!

Thanks,
Andrey Smirnov

[v1] 
https://lore.kernel.org/linux-arm-kernel/20181117181225.10737-1-andrew.smir...@gmail.com/
[github-v2] https://github.com/ndreys/linux/commits/imx8mq-pcie-v2
[imx8mq-kconfig] 
https://lore.kernel.org/linux-arm-kernel/20181114175242.12468-1-l.st...@pengutronix.de/

Andrey Smirnov (3):
  PCI: imx: No-op imx6_setup_phy_mpll() on i.MX7D
  PCI: imx: No-op imx6_pcie_reset_phy() on i.MX7D
  PCI: imx: Add support for i.MX8MQ

 .../bindings/pci/fsl,imx6q-pcie.txt   |  6 +-
 drivers/pci/controller/dwc/Kconfig|  2 +-
 drivers/pci/controller/dwc/pci-imx6.c | 87 ++-
 3 files changed, 90 insertions(+), 5 deletions(-)

-- 
2.19.1

[PATCH v2 0/3] PCIE support for i.MX8MQ

[Andrey Smirnov]

Everyone:

This series contains changes I made in order to enable support of PCIE
IP block on i.MX8MQ SoCs (full tree can be found at [github-v2]).

NOTE: The last patch have a Kconfig symbol depenency on [imx8mq-kconfig].

Changes since [v1]:

 - Driver changed to use single "fsl,controller-id" property to
   distinguish between two intances of PCIE IP block

 - All code pertaining to L1SS was dropped to simplify the patch

 - Documented additions to DT bindings

Feedback is welcome!

Thanks,
Andrey Smirnov

[v1] 
https://lore.kernel.org/linux-arm-kernel/20181117181225.10737-1-andrew.smir...@gmail.com/
[github-v2] https://github.com/ndreys/linux/commits/imx8mq-pcie-v2
[imx8mq-kconfig] 
https://lore.kernel.org/linux-arm-kernel/20181114175242.12468-1-l.st...@pengutronix.de/

Andrey Smirnov (3):
  PCI: imx: No-op imx6_setup_phy_mpll() on i.MX7D
  PCI: imx: No-op imx6_pcie_reset_phy() on i.MX7D
  PCI: imx: Add support for i.MX8MQ

 .../bindings/pci/fsl,imx6q-pcie.txt   |  6 +-
 drivers/pci/controller/dwc/Kconfig|  2 +-
 drivers/pci/controller/dwc/pci-imx6.c | 87 ++-
 3 files changed, 90 insertions(+), 5 deletions(-)

-- 
2.19.1

[PATCH V2 2/2] KVM/VMX: Fix max line length problem in the vmx_hv_remote_flush_tlb()

[lantianyu1986]

From: Lan Tianyu 

Fix max line length problem.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/vmx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6577ec8cbb0f..2356118ea440 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1596,7 +1596,7 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
}
} else {
ret = hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & 
PAGE_MASK);
+   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & PAGE_MASK);
}
 
spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
-- 
2.14.4

[PATCH V2 2/2] KVM/VMX: Fix max line length problem in the vmx_hv_remote_flush_tlb()

[lantianyu1986]

From: Lan Tianyu 

Fix max line length problem.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/vmx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6577ec8cbb0f..2356118ea440 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1596,7 +1596,7 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
}
} else {
ret = hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & 
PAGE_MASK);
+   to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & PAGE_MASK);
}
 
spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
-- 
2.14.4

[PATCH V2 1/2] KVM/VMX: Check ept_pointer before flushing ept tlb

[lantianyu1986]

From: Lan Tianyu 

This patch is to initialize ept_pointer to INVALID_PAGE and check it
before flushing ept tlb. If ept_pointer is invalid, bypass the flush
request.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/vmx.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c379d0bfdcba..6577ec8cbb0f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1582,11 +1582,18 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
/*
 * FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE hypercall needs the address of the
 * base of EPT PML4 table, strip off EPT configuration information.
+* If ept_pointer is invalid pointer, bypass the flush request.
 */
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
-   kvm_for_each_vcpu(i, vcpu, kvm)
+   kvm_for_each_vcpu(i, vcpu, kvm) {
+   u64 ept_pointer = to_vmx(vcpu)->ept_pointer;
+
+   if (!VALID_PAGE(ept_pointer))
+   continue;
+
ret |= hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer & 
PAGE_MASK);
+   ept_pointer & PAGE_MASK);
+   }
} else {
ret = hyperv_flush_guest_mapping(
to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & 
PAGE_MASK);
@@ -11614,6 +11621,8 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm 
*kvm, unsigned int id)
vmx->pi_desc.nv = POSTED_INTR_VECTOR;
vmx->pi_desc.sn = 1;
 
+   vmx->ept_pointer = INVALID_PAGE;
+
return >vcpu;
 
 free_vmcs:
-- 
2.14.4

[PATCH V2 1/2] KVM/VMX: Check ept_pointer before flushing ept tlb

[lantianyu1986]

From: Lan Tianyu 

This patch is to initialize ept_pointer to INVALID_PAGE and check it
before flushing ept tlb. If ept_pointer is invalid, bypass the flush
request.

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/vmx.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c379d0bfdcba..6577ec8cbb0f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1582,11 +1582,18 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
/*
 * FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE hypercall needs the address of the
 * base of EPT PML4 table, strip off EPT configuration information.
+* If ept_pointer is invalid pointer, bypass the flush request.
 */
if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
-   kvm_for_each_vcpu(i, vcpu, kvm)
+   kvm_for_each_vcpu(i, vcpu, kvm) {
+   u64 ept_pointer = to_vmx(vcpu)->ept_pointer;
+
+   if (!VALID_PAGE(ept_pointer))
+   continue;
+
ret |= hyperv_flush_guest_mapping(
-   to_vmx(kvm_get_vcpu(kvm, i))->ept_pointer & 
PAGE_MASK);
+   ept_pointer & PAGE_MASK);
+   }
} else {
ret = hyperv_flush_guest_mapping(
to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & 
PAGE_MASK);
@@ -11614,6 +11621,8 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm 
*kvm, unsigned int id)
vmx->pi_desc.nv = POSTED_INTR_VECTOR;
vmx->pi_desc.sn = 1;
 
+   vmx->ept_pointer = INVALID_PAGE;
+
return >vcpu;
 
 free_vmcs:
-- 
2.14.4

[PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

[Ingo Molnar]

* Sean Christopherson  wrote:

> ...instead of manually handling the case where error_code=0, e.g. to
> display "[SUPERVISOR] [READ]" instead of "normal kernel read fault".
> 
> This makes the zero case consistent with all other messages and also
> provides additional information for other error code combinations,
> e.g. error_code==1 will display "[PROT] [SUPERVISOR] [READ]" instead
> of simply "[PROT]".
> 
> Print unique names for the negative cases as opposed to e.g. "[!USER]"
> to avoid mixups due to users missing a single "!" character, and to be
> more concise for the !INSTR && !WRITE case.
> 
> Print "SUPERVISOR" in favor of "KERNEL" to reduce the likelihood that
> the message is misinterpreted as a generic kernel/software error and
> to be consistent with the SDM's nomenclature.
> 
> An alternative to passing a negated error code to err_str_append() would
> be to expand err_str_append() to take a second string for the negative
> test, but that approach complicates handling the "[READ]" case, which
> looks for !INSTR && !WRITE, e.g. it would require an extra call to
> err_str_append() and logic in err_str_append() to allow null messages
> for both the positive and negative tests.  Printing "[INSTR] [READ]"
> wouldn't be the end of the world, but a little bit of trickery in the
> kernel is a relatively small price to pay in exchange for the ability
> to unequivocally know the access type by reading a single word.
> 
> Now that all components of the message use the [] format,
> explicitly state that it's the error *code* that's being printed and
> group the err_str_append() calls by type so that the resulting print
> messages are consistent, e.g. the deciphered codes will always be:
> 
> [PROT] [USER|SUPERVISOR] [WRITE|INSTR|READ] [RSDV] [PK]
> 
> Cc: Andy Lutomirski 
> Cc: Borislav Petkov 
> Cc: Dave Hansen 
> Cc: H. Peter Anvin 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Rik van Riel 
> Cc: Thomas Gleixner 
> Cc: Yu-cheng Yu 
> Cc: linux-kernel@vger.kernel.org
> Cc: Ingo Molnar 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/x86/mm/fault.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 2ff25ad33233..0b4ce5d2b461 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -609,7 +609,7 @@ static void show_ldttss(const struct desc_ptr *gdt, const 
> char *name, u16 index)
>   */
>  static void err_str_append(unsigned long error_code, char *buf, unsigned 
> long mask, const char *txt)
>  {
> - if (error_code & mask) {
> + if ((error_code & mask) == mask) {
>   if (buf[0])
>   strcat(buf, " ");
>   strcat(buf, txt);
> @@ -655,13 +655,16 @@ show_fault_oops(struct pt_regs *regs, unsigned long 
> error_code, unsigned long ad
>* zero delimiter must fit into err_txt[].
>*/
>   err_str_append(error_code, err_txt, X86_PF_PROT,  "[PROT]" );
> - err_str_append(error_code, err_txt, X86_PF_WRITE, "[WRITE]");
>   err_str_append(error_code, err_txt, X86_PF_USER,  "[USER]" );
> - err_str_append(error_code, err_txt, X86_PF_RSVD,  "[RSVD]" );
> + err_str_append(~error_code, err_txt, X86_PF_USER, "[SUPERVISOR]");
> + err_str_append(error_code, err_txt, X86_PF_WRITE, "[WRITE]");
>   err_str_append(error_code, err_txt, X86_PF_INSTR, "[INSTR]");
> + err_str_append(~error_code, err_txt, X86_PF_WRITE | X86_PF_INSTR,
> +   "[READ]");
> + err_str_append(error_code, err_txt, X86_PF_RSVD,  "[RSVD]" );
>   err_str_append(error_code, err_txt, X86_PF_PK,"[PK]"   );
>  
> - pr_alert("#PF error: %s\n", error_code ? err_txt : "[normal kernel read 
> fault]");
> + pr_alert("#PF error code: %s\n", err_txt);
>  
>   if (!(error_code & X86_PF_USER) && user_mode(regs)) {
>   struct desc_ptr idt, gdt;

Yeah, so I don't like the overly long 'SUPERVISOR' and the somewhat 
inconsistent, sporadic handling of negatives. Here's our error code bits:

/*
 * Page fault error code bits:
 *
 *   bit 0 ==0: no page found   1: protection fault
 *   bit 1 ==0: read access 1: write access
 *   bit 2 ==0: kernel-mode access  1: user-mode access
 *   bit 3 ==   1: use of reserved bit detected
 *   bit 4 ==   1: fault was an instruction fetch
 *   bit 5 ==   1: protection keys block access
 */
enum x86_pf_error_code {
X86_PF_PROT =   1 << 0,
X86_PF_WRITE=   1 << 1,
X86_PF_USER =   1 << 2,
X86_PF_RSVD =   1 << 3,
X86_PF_INSTR=   1 << 4,
X86_PF_PK   =   1 << 5,
};

While not all of these combinations will happen on real hardware, I think 
the message should nevertheless be fixed length and be of a predictable 
nature.

I like 

[PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

[Ingo Molnar]

* Sean Christopherson  wrote:

> ...instead of manually handling the case where error_code=0, e.g. to
> display "[SUPERVISOR] [READ]" instead of "normal kernel read fault".
> 
> This makes the zero case consistent with all other messages and also
> provides additional information for other error code combinations,
> e.g. error_code==1 will display "[PROT] [SUPERVISOR] [READ]" instead
> of simply "[PROT]".
> 
> Print unique names for the negative cases as opposed to e.g. "[!USER]"
> to avoid mixups due to users missing a single "!" character, and to be
> more concise for the !INSTR && !WRITE case.
> 
> Print "SUPERVISOR" in favor of "KERNEL" to reduce the likelihood that
> the message is misinterpreted as a generic kernel/software error and
> to be consistent with the SDM's nomenclature.
> 
> An alternative to passing a negated error code to err_str_append() would
> be to expand err_str_append() to take a second string for the negative
> test, but that approach complicates handling the "[READ]" case, which
> looks for !INSTR && !WRITE, e.g. it would require an extra call to
> err_str_append() and logic in err_str_append() to allow null messages
> for both the positive and negative tests.  Printing "[INSTR] [READ]"
> wouldn't be the end of the world, but a little bit of trickery in the
> kernel is a relatively small price to pay in exchange for the ability
> to unequivocally know the access type by reading a single word.
> 
> Now that all components of the message use the [] format,
> explicitly state that it's the error *code* that's being printed and
> group the err_str_append() calls by type so that the resulting print
> messages are consistent, e.g. the deciphered codes will always be:
> 
> [PROT] [USER|SUPERVISOR] [WRITE|INSTR|READ] [RSDV] [PK]
> 
> Cc: Andy Lutomirski 
> Cc: Borislav Petkov 
> Cc: Dave Hansen 
> Cc: H. Peter Anvin 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Rik van Riel 
> Cc: Thomas Gleixner 
> Cc: Yu-cheng Yu 
> Cc: linux-kernel@vger.kernel.org
> Cc: Ingo Molnar 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/x86/mm/fault.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 2ff25ad33233..0b4ce5d2b461 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -609,7 +609,7 @@ static void show_ldttss(const struct desc_ptr *gdt, const 
> char *name, u16 index)
>   */
>  static void err_str_append(unsigned long error_code, char *buf, unsigned 
> long mask, const char *txt)
>  {
> - if (error_code & mask) {
> + if ((error_code & mask) == mask) {
>   if (buf[0])
>   strcat(buf, " ");
>   strcat(buf, txt);
> @@ -655,13 +655,16 @@ show_fault_oops(struct pt_regs *regs, unsigned long 
> error_code, unsigned long ad
>* zero delimiter must fit into err_txt[].
>*/
>   err_str_append(error_code, err_txt, X86_PF_PROT,  "[PROT]" );
> - err_str_append(error_code, err_txt, X86_PF_WRITE, "[WRITE]");
>   err_str_append(error_code, err_txt, X86_PF_USER,  "[USER]" );
> - err_str_append(error_code, err_txt, X86_PF_RSVD,  "[RSVD]" );
> + err_str_append(~error_code, err_txt, X86_PF_USER, "[SUPERVISOR]");
> + err_str_append(error_code, err_txt, X86_PF_WRITE, "[WRITE]");
>   err_str_append(error_code, err_txt, X86_PF_INSTR, "[INSTR]");
> + err_str_append(~error_code, err_txt, X86_PF_WRITE | X86_PF_INSTR,
> +   "[READ]");
> + err_str_append(error_code, err_txt, X86_PF_RSVD,  "[RSVD]" );
>   err_str_append(error_code, err_txt, X86_PF_PK,"[PK]"   );
>  
> - pr_alert("#PF error: %s\n", error_code ? err_txt : "[normal kernel read 
> fault]");
> + pr_alert("#PF error code: %s\n", err_txt);
>  
>   if (!(error_code & X86_PF_USER) && user_mode(regs)) {
>   struct desc_ptr idt, gdt;

Yeah, so I don't like the overly long 'SUPERVISOR' and the somewhat 
inconsistent, sporadic handling of negatives. Here's our error code bits:

/*
 * Page fault error code bits:
 *
 *   bit 0 ==0: no page found   1: protection fault
 *   bit 1 ==0: read access 1: write access
 *   bit 2 ==0: kernel-mode access  1: user-mode access
 *   bit 3 ==   1: use of reserved bit detected
 *   bit 4 ==   1: fault was an instruction fetch
 *   bit 5 ==   1: protection keys block access
 */
enum x86_pf_error_code {
X86_PF_PROT =   1 << 0,
X86_PF_WRITE=   1 << 1,
X86_PF_USER =   1 << 2,
X86_PF_RSVD =   1 << 3,
X86_PF_INSTR=   1 << 4,
X86_PF_PK   =   1 << 5,
};

While not all of these combinations will happen on real hardware, I think 
the message should nevertheless be fixed length and be of a predictable 
nature.

I like 

[PATCH] proc/sysctl: fix return error for proc_doulongvec_minmax

[Cheng Lin]

If the number of input parameters is less than the total
parameters, an EINVAL error will be returned.

e.g.
We use proc_doulongvec_minmax to pass up to two parameters
with kern_table.

{
.procname   = "monitor_signals",
.data   = _sigs,
.maxlen = 2*sizeof(unsigned long),
.mode   = 0644,
.proc_handler   = proc_doulongvec_minmax,
},

Reproduce:
When passing two parameters, it's work normal. But passing
only one parameter, an error "Invalid argument"(EINVAL) is
returned.

[root@cl150 ~]# echo 1 2 > /proc/sys/kernel/monitor_signals
[root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
1   2
[root@cl150 ~]# echo 3 > /proc/sys/kernel/monitor_signals
-bash: echo: write error: Invalid argument
[root@cl150 ~]# echo $?
1
[root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
3   2
[root@cl150 ~]#

The following is the result after apply this patch. No error
is returned when the number of input parameters is less than
the total parameters.

[root@cl150 ~]# echo 1 2 > /proc/sys/kernel/monitor_signals
[root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
1   2
[root@cl150 ~]# echo 3 > /proc/sys/kernel/monitor_signals
[root@cl150 ~]# echo $?
0
[root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
3   2
[root@cl150 ~]#

There are three processing functions dealing with digital parameters,
__do_proc_dointvec/__do_proc_douintvec/__do_proc_doulongvec_minmax.

This patch deals with __do_proc_doulongvec_minmax, just as
__do_proc_dointvec does, adding a check for parameters 'left'. In
__do_proc_douintvec, its code implementation explicitly does not
support multiple inputs.

static int __do_proc_douintvec(...){
 ...
 /*
  * Arrays are not supported, keep this simple. *Do not* add
  * support for them.
  */
 if (vleft != 1) {
 *lenp = 0;
 return -EINVAL;
 }
 ...
}

So, just __do_proc_doulongvec_minmax has the problem. And most use of
proc_doulongvec_minmax/proc_doulongvec_ms_jiffies_minmax just have one
parameter.

Signed-off-by: Cheng Lin 
---
 kernel/sysctl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 5fc724e..9ee261f 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2779,6 +2779,8 @@ static int __do_proc_doulongvec_minmax(void *data, struct 
ctl_table *table, int
bool neg;
 
left -= proc_skip_spaces();
+   if (!left)
+   break;
 
err = proc_get_long(, , , ,
 proc_wspace_sep,
-- 
1.8.3.1

[PATCH] proc/sysctl: fix return error for proc_doulongvec_minmax

[Cheng Lin]

If the number of input parameters is less than the total
parameters, an EINVAL error will be returned.

e.g.
We use proc_doulongvec_minmax to pass up to two parameters
with kern_table.

{
.procname   = "monitor_signals",
.data   = _sigs,
.maxlen = 2*sizeof(unsigned long),
.mode   = 0644,
.proc_handler   = proc_doulongvec_minmax,
},

Reproduce:
When passing two parameters, it's work normal. But passing
only one parameter, an error "Invalid argument"(EINVAL) is
returned.

[root@cl150 ~]# echo 1 2 > /proc/sys/kernel/monitor_signals
[root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
1   2
[root@cl150 ~]# echo 3 > /proc/sys/kernel/monitor_signals
-bash: echo: write error: Invalid argument
[root@cl150 ~]# echo $?
1
[root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
3   2
[root@cl150 ~]#

The following is the result after apply this patch. No error
is returned when the number of input parameters is less than
the total parameters.

[root@cl150 ~]# echo 1 2 > /proc/sys/kernel/monitor_signals
[root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
1   2
[root@cl150 ~]# echo 3 > /proc/sys/kernel/monitor_signals
[root@cl150 ~]# echo $?
0
[root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
3   2
[root@cl150 ~]#

There are three processing functions dealing with digital parameters,
__do_proc_dointvec/__do_proc_douintvec/__do_proc_doulongvec_minmax.

This patch deals with __do_proc_doulongvec_minmax, just as
__do_proc_dointvec does, adding a check for parameters 'left'. In
__do_proc_douintvec, its code implementation explicitly does not
support multiple inputs.

static int __do_proc_douintvec(...){
 ...
 /*
  * Arrays are not supported, keep this simple. *Do not* add
  * support for them.
  */
 if (vleft != 1) {
 *lenp = 0;
 return -EINVAL;
 }
 ...
}

So, just __do_proc_doulongvec_minmax has the problem. And most use of
proc_doulongvec_minmax/proc_doulongvec_ms_jiffies_minmax just have one
parameter.

Signed-off-by: Cheng Lin 
---
 kernel/sysctl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 5fc724e..9ee261f 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2779,6 +2779,8 @@ static int __do_proc_doulongvec_minmax(void *data, struct 
ctl_table *table, int
bool neg;
 
left -= proc_skip_spaces();
+   if (!left)
+   break;
 
err = proc_get_long(, , , ,
 proc_wspace_sep,
-- 
1.8.3.1

Re: [RFC PATCH] clk: qcom: clk-rpmh: Add IPA clock support

[Bjorn Andersson]

On Tue 04 Dec 23:15 PST 2018, Stephen Boyd wrote:

> Quoting David Dai (2018-12-04 17:14:10)
> > 
> > On 12/4/2018 2:34 PM, Stephen Boyd wrote:
> > > Quoting Alex Elder (2018-12-04 13:41:47)
> > >> On 12/4/18 1:24 PM, Stephen Boyd wrote:
> > >>> Quoting David Dai (2018-12-03 19:50:13)
> >  Add IPA clock support by extending the current clk rpmh driver to 
> >  support
> >  clocks that are managed by a different type of RPMh resource known as
> >  Bus Clock Manager(BCM).
> > >>> Yes, but why? Does the IPA driver need to set clk rates and that somehow
> > >>> doesn't work as a bandwidth request?
> > >> The IPA core clock is a *clock*, not a bus.  Representing it as if
> > >> it were a bus, abusing the interconnect interface--pretending a bandwidth
> > >> request is really a clock rate request--is kind of kludgy.  I think Bjorn
> > >> and David (and maybe Georgi? I don't know) decided a long time ago that
> > >> exposing this as a clock is the right way to do it.  I agree with that.
> > >>
> > > But then we translate that clock rate into a bandwidth request to the
> > > BCM hardware? Seems really weird because it's doing the opposite of what
> > > you say is abusive. What does the IPA driver plan to do with this clk?
> > > Calculate a frequency by knowing that it really boils down to some
> > > bandwidth that then gets converted back into some clock frequency? Do we
> > > have the user somewhere that can be pointed to?
> > The clock rate is translated into a unitless threshold value sent as 
> > part of the rpmh msg
> > that BCM takes to select a performance. In this case, the unit 
> > conversion is based on
> > the unit value read from the aux data which is in Khz. I understand that 
> > this wasn't
> > explicitly mentioned anywhere and I'll improve on that next patch. 
> 
> How is this different from bus bandwidth requests? In those cases the
> bandwidth is calculated in bits per second or something like that, and
> written to the hardware so it can convert that bandwidth into kHz and
> set a bus clk frequency in the clock controller? So in the IPA case
> we've skipped the bps to kHz conversion step and gone straight to the
> clk frequency setting part? Is a BCM able to aggregate units of
> bandwidth or kHz depending on how it's configured and this BCM is
> configured for kHz?
> 

My objection to the use of msm_bus vs clock framework is not related to
how the actual interface of configuring the hardware looks like. It's
simply a matter of how this is represented in software, between some
provider and the IPA driver.

The IPA driver wants the IPA block to tick at 75MHz and I do not think
it's appropriate to achieve that by requesting a path between IPA Core
and IPA Core of 7500 Kbytes/s.

Regards,
Bjorn

[PATCH v2 3/3] ntb_hw_switchtec: Added support of >=4G memory windows

[Wesley Sheng]

From: Paul Selles 

Current Switchtec's BAR setup registers are limited to 32bits,
corresponding to the maximum MW (memory window) size is <4G.

Increase the MW sizes with the addition of the BAR Setup Extension
Register for the upper 32bits of a 64bits MW size. This increases the MW
range to between 4K and 2^63.

Reported-by: Boris Glimcher 
Signed-off-by: Paul Selles 
Signed-off-by: Wesley Sheng 
Reviewed-by: Logan Gunthorpe 
---
 drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 9 +++--
 include/linux/switchtec.h  | 6 +-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c 
b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
index 9916bc5..f6f0035 100644
--- a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
+++ b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
@@ -264,6 +264,7 @@ static void switchtec_ntb_mw_clr_direct(struct 
switchtec_ntb *sndev, int idx)
ctl_val &= ~NTB_CTRL_BAR_DIR_WIN_EN;
iowrite32(ctl_val, >bar_entry[bar].ctl);
iowrite32(0, >bar_entry[bar].win_size);
+   iowrite32(0, >bar_ext_entry[bar].win_size);
iowrite64(sndev->self_partition, >bar_entry[bar].xlate_addr);
 }
 
@@ -286,7 +287,9 @@ static void switchtec_ntb_mw_set_direct(struct 
switchtec_ntb *sndev, int idx,
ctl_val |= NTB_CTRL_BAR_DIR_WIN_EN;
 
iowrite32(ctl_val, >bar_entry[bar].ctl);
-   iowrite32(xlate_pos | size, >bar_entry[bar].win_size);
+   iowrite32(xlate_pos | (lower_32_bits(size) & 0xF000),
+ >bar_entry[bar].win_size);
+   iowrite32(upper_32_bits(size), >bar_ext_entry[bar].win_size);
iowrite64(sndev->self_partition | addr,
  >bar_entry[bar].xlate_addr);
 }
@@ -1053,7 +1056,9 @@ static int crosslink_setup_mws(struct switchtec_ntb 
*sndev, int ntb_lut_idx,
ctl_val |= NTB_CTRL_BAR_DIR_WIN_EN;
 
iowrite32(ctl_val, >bar_entry[bar].ctl);
-   iowrite32(xlate_pos | size, >bar_entry[bar].win_size);
+   iowrite32(xlate_pos | (lower_32_bits(size) & 0xF000),
+ >bar_entry[bar].win_size);
+   iowrite32(upper_32_bits(size), 
>bar_ext_entry[bar].win_size);
iowrite64(sndev->peer_partition | addr,
  >bar_entry[bar].xlate_addr);
}
diff --git a/include/linux/switchtec.h b/include/linux/switchtec.h
index 623719c9..64aa25e 100644
--- a/include/linux/switchtec.h
+++ b/include/linux/switchtec.h
@@ -243,7 +243,11 @@ struct ntb_ctrl_regs {
u32 win_size;
u64 xlate_addr;
} bar_entry[6];
-   u32 reserved2[216];
+   struct {
+   u32 win_size;
+   u32 reserved[3];
+   } bar_ext_entry[6];
+   u32 reserved2[192];
u32 req_id_table[512];
u32 reserved3[256];
u64 lut_entry[512];
-- 
2.7.4

[PATCH v2 2/3] ntb_hw_switchtec: NT req id mapping table register entry number should be 512

[Wesley Sheng]

The number of available NT req id mapping table entries per NTB control
register is 512. The driver mistakenly limits the number to 256.

Fix the array size of NT req id mapping table.

Fixes: c082b04c9d40 ("NTB: switchtec: Add NTB hardware register definitions")
Signed-off-by: Wesley Sheng 
Reviewed-by: Logan Gunthorpe 
---
 include/linux/switchtec.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/switchtec.h b/include/linux/switchtec.h
index ab400af..623719c9 100644
--- a/include/linux/switchtec.h
+++ b/include/linux/switchtec.h
@@ -244,8 +244,8 @@ struct ntb_ctrl_regs {
u64 xlate_addr;
} bar_entry[6];
u32 reserved2[216];
-   u32 req_id_table[256];
-   u32 reserved3[512];
+   u32 req_id_table[512];
+   u32 reserved3[256];
u64 lut_entry[512];
 } __packed;
 
-- 
2.7.4

[PATCH v2 0/3] ntb_hw_switchtec: Added support of >=4G memory windows

[Wesley Sheng]

Hi, Everyone,

This patch series adds support of >=4G memory windows.

Current Switchtec's BAR setup registers are limited to 32bits,
corresponding to the maximum MW (memory window) size is <4G.
Increase the MW sizes with the addition of the BAR Setup Extension
Register for the upper 32bits of a 64bits MW size. This increases the MW
range to between 4K and 2^63.

Additionally, we've made the following changes:

* debug print 64bit aligned crosslink BAR numbers
* Fix the array size of NT req id mapping table

Tested with ntb_test.sh successfully based on NTB fixes series from
Logan Gunthorpe  at 
https://github.com/sbates130272/linux-p2pmem on branch of
ntb_multiport_fixes

Regards,
Wesley

--

Changed since v1:
  - Using upper_32_bits() and lower_32_bits() marcos makes it easier
to read and avoids compiler warning on 32-bit arch
  - Reorder the patches to make the bug fixes first and add a "Fixes"
line to the commit messages

--
Paul Selles (2):
  ntb_hw_switchtec: debug print 64bit aligned crosslink BAR Numbers
  ntb_hw_switchtec: Added support of >=4G memory windows

Wesley Sheng (1):
  ntb_hw_switchtec: NT req id mapping table register entry number should
be 512

 drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 11 ---
 include/linux/switchtec.h  | 10 +++---
 2 files changed, 15 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH v2 3/3] ntb_hw_switchtec: Added support of >=4G memory windows

[Wesley Sheng]

From: Paul Selles 

Current Switchtec's BAR setup registers are limited to 32bits,
corresponding to the maximum MW (memory window) size is <4G.

Increase the MW sizes with the addition of the BAR Setup Extension
Register for the upper 32bits of a 64bits MW size. This increases the MW
range to between 4K and 2^63.

Reported-by: Boris Glimcher 
Signed-off-by: Paul Selles 
Signed-off-by: Wesley Sheng 
Reviewed-by: Logan Gunthorpe 
---
 drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 9 +++--
 include/linux/switchtec.h  | 6 +-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c 
b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
index 9916bc5..f6f0035 100644
--- a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
+++ b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
@@ -264,6 +264,7 @@ static void switchtec_ntb_mw_clr_direct(struct 
switchtec_ntb *sndev, int idx)
ctl_val &= ~NTB_CTRL_BAR_DIR_WIN_EN;
iowrite32(ctl_val, >bar_entry[bar].ctl);
iowrite32(0, >bar_entry[bar].win_size);
+   iowrite32(0, >bar_ext_entry[bar].win_size);
iowrite64(sndev->self_partition, >bar_entry[bar].xlate_addr);
 }
 
@@ -286,7 +287,9 @@ static void switchtec_ntb_mw_set_direct(struct 
switchtec_ntb *sndev, int idx,
ctl_val |= NTB_CTRL_BAR_DIR_WIN_EN;
 
iowrite32(ctl_val, >bar_entry[bar].ctl);
-   iowrite32(xlate_pos | size, >bar_entry[bar].win_size);
+   iowrite32(xlate_pos | (lower_32_bits(size) & 0xF000),
+ >bar_entry[bar].win_size);
+   iowrite32(upper_32_bits(size), >bar_ext_entry[bar].win_size);
iowrite64(sndev->self_partition | addr,
  >bar_entry[bar].xlate_addr);
 }
@@ -1053,7 +1056,9 @@ static int crosslink_setup_mws(struct switchtec_ntb 
*sndev, int ntb_lut_idx,
ctl_val |= NTB_CTRL_BAR_DIR_WIN_EN;
 
iowrite32(ctl_val, >bar_entry[bar].ctl);
-   iowrite32(xlate_pos | size, >bar_entry[bar].win_size);
+   iowrite32(xlate_pos | (lower_32_bits(size) & 0xF000),
+ >bar_entry[bar].win_size);
+   iowrite32(upper_32_bits(size), 
>bar_ext_entry[bar].win_size);
iowrite64(sndev->peer_partition | addr,
  >bar_entry[bar].xlate_addr);
}
diff --git a/include/linux/switchtec.h b/include/linux/switchtec.h
index 623719c9..64aa25e 100644
--- a/include/linux/switchtec.h
+++ b/include/linux/switchtec.h
@@ -243,7 +243,11 @@ struct ntb_ctrl_regs {
u32 win_size;
u64 xlate_addr;
} bar_entry[6];
-   u32 reserved2[216];
+   struct {
+   u32 win_size;
+   u32 reserved[3];
+   } bar_ext_entry[6];
+   u32 reserved2[192];
u32 req_id_table[512];
u32 reserved3[256];
u64 lut_entry[512];
-- 
2.7.4

[PATCH v2 2/3] ntb_hw_switchtec: NT req id mapping table register entry number should be 512

[Wesley Sheng]

The number of available NT req id mapping table entries per NTB control
register is 512. The driver mistakenly limits the number to 256.

Fix the array size of NT req id mapping table.

Fixes: c082b04c9d40 ("NTB: switchtec: Add NTB hardware register definitions")
Signed-off-by: Wesley Sheng 
Reviewed-by: Logan Gunthorpe 
---
 include/linux/switchtec.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/switchtec.h b/include/linux/switchtec.h
index ab400af..623719c9 100644
--- a/include/linux/switchtec.h
+++ b/include/linux/switchtec.h
@@ -244,8 +244,8 @@ struct ntb_ctrl_regs {
u64 xlate_addr;
} bar_entry[6];
u32 reserved2[216];
-   u32 req_id_table[256];
-   u32 reserved3[512];
+   u32 req_id_table[512];
+   u32 reserved3[256];
u64 lut_entry[512];
 } __packed;
 
-- 
2.7.4

[PATCH v2 0/3] ntb_hw_switchtec: Added support of >=4G memory windows

[Wesley Sheng]

Hi, Everyone,

This patch series adds support of >=4G memory windows.

Current Switchtec's BAR setup registers are limited to 32bits,
corresponding to the maximum MW (memory window) size is <4G.
Increase the MW sizes with the addition of the BAR Setup Extension
Register for the upper 32bits of a 64bits MW size. This increases the MW
range to between 4K and 2^63.

Additionally, we've made the following changes:

* debug print 64bit aligned crosslink BAR numbers
* Fix the array size of NT req id mapping table

Tested with ntb_test.sh successfully based on NTB fixes series from
Logan Gunthorpe  at 
https://github.com/sbates130272/linux-p2pmem on branch of
ntb_multiport_fixes

Regards,
Wesley

--

Changed since v1:
  - Using upper_32_bits() and lower_32_bits() marcos makes it easier
to read and avoids compiler warning on 32-bit arch
  - Reorder the patches to make the bug fixes first and add a "Fixes"
line to the commit messages

--
Paul Selles (2):
  ntb_hw_switchtec: debug print 64bit aligned crosslink BAR Numbers
  ntb_hw_switchtec: Added support of >=4G memory windows

Wesley Sheng (1):
  ntb_hw_switchtec: NT req id mapping table register entry number should
be 512

 drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 11 ---
 include/linux/switchtec.h  | 10 +++---
 2 files changed, 15 insertions(+), 6 deletions(-)

-- 
2.7.4

Re: [RFC PATCH] clk: qcom: clk-rpmh: Add IPA clock support

[Bjorn Andersson]

On Tue 04 Dec 23:15 PST 2018, Stephen Boyd wrote:

> Quoting David Dai (2018-12-04 17:14:10)
> > 
> > On 12/4/2018 2:34 PM, Stephen Boyd wrote:
> > > Quoting Alex Elder (2018-12-04 13:41:47)
> > >> On 12/4/18 1:24 PM, Stephen Boyd wrote:
> > >>> Quoting David Dai (2018-12-03 19:50:13)
> >  Add IPA clock support by extending the current clk rpmh driver to 
> >  support
> >  clocks that are managed by a different type of RPMh resource known as
> >  Bus Clock Manager(BCM).
> > >>> Yes, but why? Does the IPA driver need to set clk rates and that somehow
> > >>> doesn't work as a bandwidth request?
> > >> The IPA core clock is a *clock*, not a bus.  Representing it as if
> > >> it were a bus, abusing the interconnect interface--pretending a bandwidth
> > >> request is really a clock rate request--is kind of kludgy.  I think Bjorn
> > >> and David (and maybe Georgi? I don't know) decided a long time ago that
> > >> exposing this as a clock is the right way to do it.  I agree with that.
> > >>
> > > But then we translate that clock rate into a bandwidth request to the
> > > BCM hardware? Seems really weird because it's doing the opposite of what
> > > you say is abusive. What does the IPA driver plan to do with this clk?
> > > Calculate a frequency by knowing that it really boils down to some
> > > bandwidth that then gets converted back into some clock frequency? Do we
> > > have the user somewhere that can be pointed to?
> > The clock rate is translated into a unitless threshold value sent as 
> > part of the rpmh msg
> > that BCM takes to select a performance. In this case, the unit 
> > conversion is based on
> > the unit value read from the aux data which is in Khz. I understand that 
> > this wasn't
> > explicitly mentioned anywhere and I'll improve on that next patch. 
> 
> How is this different from bus bandwidth requests? In those cases the
> bandwidth is calculated in bits per second or something like that, and
> written to the hardware so it can convert that bandwidth into kHz and
> set a bus clk frequency in the clock controller? So in the IPA case
> we've skipped the bps to kHz conversion step and gone straight to the
> clk frequency setting part? Is a BCM able to aggregate units of
> bandwidth or kHz depending on how it's configured and this BCM is
> configured for kHz?
> 

My objection to the use of msm_bus vs clock framework is not related to
how the actual interface of configuring the hardware looks like. It's
simply a matter of how this is represented in software, between some
provider and the IPA driver.

The IPA driver wants the IPA block to tick at 75MHz and I do not think
it's appropriate to achieve that by requesting a path between IPA Core
and IPA Core of 7500 Kbytes/s.

Regards,
Bjorn

[PATCH v2 1/3] ntb_hw_switchtec: debug print 64bit aligned crosslink BAR Numbers

[Wesley Sheng]

From: Paul Selles 

Switchtec NTB crosslink BARs are 64bit addressed but they are printed as
32bit addressed BARs. Fix debug log to increment the BAR numbers by 2 to
reflect the 64bit address alignment.

Fixes: 017525018202 ("ntb_hw_switchtec: Add initialization code for crosslink")
Signed-off-by: Paul Selles 
Signed-off-by: Wesley Sheng 
Reviewed-by: Logan Gunthorpe 
---
 drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c 
b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
index 5ee5f40..9916bc5 100644
--- a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
+++ b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
@@ -1120,7 +1120,7 @@ static int crosslink_enum_partition(struct switchtec_ntb 
*sndev,
 
dev_dbg(>stdev->dev,
"Crosslink BAR%d addr: %llx\n",
-   i, bar_addr);
+   i*2, bar_addr);
 
if (bar_addr != bar_space * i)
continue;
-- 
2.7.4

[PATCH v2 1/3] ntb_hw_switchtec: debug print 64bit aligned crosslink BAR Numbers

[Wesley Sheng]

From: Paul Selles 

Switchtec NTB crosslink BARs are 64bit addressed but they are printed as
32bit addressed BARs. Fix debug log to increment the BAR numbers by 2 to
reflect the 64bit address alignment.

Fixes: 017525018202 ("ntb_hw_switchtec: Add initialization code for crosslink")
Signed-off-by: Paul Selles 
Signed-off-by: Wesley Sheng 
Reviewed-by: Logan Gunthorpe 
---
 drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c 
b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
index 5ee5f40..9916bc5 100644
--- a/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
+++ b/drivers/ntb/hw/mscc/ntb_hw_switchtec.c
@@ -1120,7 +1120,7 @@ static int crosslink_enum_partition(struct switchtec_ntb 
*sndev,
 
dev_dbg(>stdev->dev,
"Crosslink BAR%d addr: %llx\n",
-   i, bar_addr);
+   i*2, bar_addr);
 
if (bar_addr != bar_space * i)
continue;
-- 
2.7.4

Re: [PATCH linux-next v3 6/7] ASoC: rsnd: add avb clocks

[Jiada Wang]

Hi Morimoto-san


On 2018/12/06 14:38, Kuninori Morimoto wrote:

Hi Jiada


SMSTPCR922 controls input of two clocks "S0D1ϕ" and "S0D4ϕ",

Ahh, OK I could check it via Block diagram.
But it is "Module stop" for these, anyway.
"Module stop" and "S0D1ϕ/S0D4ϕ" are completely different clocks.

Yes, "module stop" is different from "S0D1ϕ/S0D4ϕ",
both clk_i and avb_counter8's parent clock is same "module stop" clock,
which is < CPG_MOD 922>, it is a shared gate clock between
avb_counter8 and clk_i





"S0D4ϕ" is input to BRGA,
"S0D1ϕ" is input to avb_counter8

It seems we need to update "clk_i" portion first for this purpose.
Then, we need to consider about Gen2 vs Gen3, etc, etc...
It seems we can't keep patch simple...

Yes, I know it's not simple, so I want to discuss with you,
how we can proceed on this topic,
by adding avb_counter8, rcar audio can support arbitrary clock rate,
which is a desired feature, IMO


3rd, we need to create new clock/handler for
avb_counter8 / audio_clk_div3 / avb_div8 for "internal" purpose,
and need to create avb_adg_syn[] clock for "external" purpose for EAVB/IF.
Your code is creating / registering adg->clkavb[],
but it is for avb_counter8 in my understanding.
We don't need to register it as formal clock IMO.

I agree, besides avb_counter8 there are other clocks which need to be
added as you have mentioned,
in this patch-set, I only added avb_counter8, because I want to keep
the patch-set simple,
other clocks can be added later.

No, No, No.
avb_counter8 is just "internal" clock, and one of
parent clock for avb_div8 which is needed for avb_adg_syn[].
We need to control/register is avb_adg_syn[], not avb_counter8.

Your approach on this patch is very "Quick-Hack".
I have no objection for out-of-tree patches.
But, "Quick-Hack approach with changing formal DT on upstream"
is nightmare.


avb_counter8 is registered as formal clock is because,
there is use case that EAVB-IF may use avb_div8, and avb_counter8 is
input to avb_div8.
if keeps avb_counter8 'internal', I am not sure how EAVB-IF can set
clock rate for avb_counter8

EAVB/IF driver setups avb_adg_syn[].
Then, ADG considers/searchs avb_counter8/avb_div8/audio_clk_div3
settings internally.
Don't control avb_counter8 directly from EAVB.

OK, I think I understand your point,
which avb_counter8 / avb_div8/audio_clk_div3 need to be used,
only need to be considered by adg internally.

Thanks,
Jiada


Best regards
---
Kuninori Morimoto

Re: [PATCH linux-next v3 6/7] ASoC: rsnd: add avb clocks

[Jiada Wang]

Hi Morimoto-san


On 2018/12/06 14:38, Kuninori Morimoto wrote:

Hi Jiada


SMSTPCR922 controls input of two clocks "S0D1ϕ" and "S0D4ϕ",

Ahh, OK I could check it via Block diagram.
But it is "Module stop" for these, anyway.
"Module stop" and "S0D1ϕ/S0D4ϕ" are completely different clocks.

Yes, "module stop" is different from "S0D1ϕ/S0D4ϕ",
both clk_i and avb_counter8's parent clock is same "module stop" clock,
which is < CPG_MOD 922>, it is a shared gate clock between
avb_counter8 and clk_i





"S0D4ϕ" is input to BRGA,
"S0D1ϕ" is input to avb_counter8

It seems we need to update "clk_i" portion first for this purpose.
Then, we need to consider about Gen2 vs Gen3, etc, etc...
It seems we can't keep patch simple...

Yes, I know it's not simple, so I want to discuss with you,
how we can proceed on this topic,
by adding avb_counter8, rcar audio can support arbitrary clock rate,
which is a desired feature, IMO


3rd, we need to create new clock/handler for
avb_counter8 / audio_clk_div3 / avb_div8 for "internal" purpose,
and need to create avb_adg_syn[] clock for "external" purpose for EAVB/IF.
Your code is creating / registering adg->clkavb[],
but it is for avb_counter8 in my understanding.
We don't need to register it as formal clock IMO.

I agree, besides avb_counter8 there are other clocks which need to be
added as you have mentioned,
in this patch-set, I only added avb_counter8, because I want to keep
the patch-set simple,
other clocks can be added later.

No, No, No.
avb_counter8 is just "internal" clock, and one of
parent clock for avb_div8 which is needed for avb_adg_syn[].
We need to control/register is avb_adg_syn[], not avb_counter8.

Your approach on this patch is very "Quick-Hack".
I have no objection for out-of-tree patches.
But, "Quick-Hack approach with changing formal DT on upstream"
is nightmare.


avb_counter8 is registered as formal clock is because,
there is use case that EAVB-IF may use avb_div8, and avb_counter8 is
input to avb_div8.
if keeps avb_counter8 'internal', I am not sure how EAVB-IF can set
clock rate for avb_counter8

EAVB/IF driver setups avb_adg_syn[].
Then, ADG considers/searchs avb_counter8/avb_div8/audio_clk_div3
settings internally.
Don't control avb_counter8 directly from EAVB.

OK, I think I understand your point,
which avb_counter8 / avb_div8/audio_clk_div3 need to be used,
only need to be considered by adg internally.

Thanks,
Jiada


Best regards
---
Kuninori Morimoto

[PATCH 3/5] irqchip/irq-imx-gpcv2: Make use of BIT() macro

[Andrey Smirnov]

Convert all instances of 1 << x to BIT(x) for consistency with other
kernel code.

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index b262ba8b2652..077d56b3183a 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -78,7 +78,7 @@ static int imx_gpcv2_irq_set_wake(struct irq_data *d, 
unsigned int on)
u32 mask, val;
 
raw_spin_lock_irqsave(>rlock, flags);
-   mask = 1 << d->hwirq % 32;
+   mask = BIT(d->hwirq % 32);
val = cd->wakeup_sources[idx];
 
cd->wakeup_sources[idx] = on ? (val & ~mask) : (val | mask);
@@ -101,7 +101,7 @@ static void imx_gpcv2_irq_unmask(struct irq_data *d)
raw_spin_lock(>rlock);
reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
val = readl_relaxed(reg);
-   val &= ~(1 << d->hwirq % 32);
+   val &= ~BIT(d->hwirq % 32);
writel_relaxed(val, reg);
raw_spin_unlock(>rlock);
 
@@ -117,7 +117,7 @@ static void imx_gpcv2_irq_mask(struct irq_data *d)
raw_spin_lock(>rlock);
reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
val = readl_relaxed(reg);
-   val |= 1 << (d->hwirq % 32);
+   val |= BIT(d->hwirq % 32);
writel_relaxed(val, reg);
raw_spin_unlock(>rlock);
 
-- 
2.19.1

[PATCH 3/5] irqchip/irq-imx-gpcv2: Make use of BIT() macro

[Andrey Smirnov]

Convert all instances of 1 << x to BIT(x) for consistency with other
kernel code.

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index b262ba8b2652..077d56b3183a 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -78,7 +78,7 @@ static int imx_gpcv2_irq_set_wake(struct irq_data *d, 
unsigned int on)
u32 mask, val;
 
raw_spin_lock_irqsave(>rlock, flags);
-   mask = 1 << d->hwirq % 32;
+   mask = BIT(d->hwirq % 32);
val = cd->wakeup_sources[idx];
 
cd->wakeup_sources[idx] = on ? (val & ~mask) : (val | mask);
@@ -101,7 +101,7 @@ static void imx_gpcv2_irq_unmask(struct irq_data *d)
raw_spin_lock(>rlock);
reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
val = readl_relaxed(reg);
-   val &= ~(1 << d->hwirq % 32);
+   val &= ~BIT(d->hwirq % 32);
writel_relaxed(val, reg);
raw_spin_unlock(>rlock);
 
@@ -117,7 +117,7 @@ static void imx_gpcv2_irq_mask(struct irq_data *d)
raw_spin_lock(>rlock);
reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
val = readl_relaxed(reg);
-   val |= 1 << (d->hwirq % 32);
+   val |= BIT(d->hwirq % 32);
writel_relaxed(val, reg);
raw_spin_unlock(>rlock);
 
-- 
2.19.1

[PATCH 2/5] irqchip/irq-imx-gpcv2: Share reg offset calculation code

[Andrey Smirnov]

Move identical offset calculation code into a small helper function
and make use of it in the rest of the code.

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index cbed00319315..b262ba8b2652 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -28,6 +28,11 @@ struct gpcv2_irqchip_data {
 
 static struct gpcv2_irqchip_data *imx_gpcv2_instance;
 
+static void __iomem *gpcv2_idx_to_reg(struct gpcv2_irqchip_data *cd, int i)
+{
+   return cd->gpc_base + cd->cpu2wakeup + i * 4;
+}
+
 static int gpcv2_wakeup_source_save(void)
 {
struct gpcv2_irqchip_data *cd;
@@ -39,7 +44,7 @@ static int gpcv2_wakeup_source_save(void)
return 0;
 
for (i = 0; i < IMR_NUM; i++) {
-   reg = cd->gpc_base + cd->cpu2wakeup + i * 4;
+   reg = gpcv2_idx_to_reg(cd, i);
cd->saved_irq_mask[i] = readl_relaxed(reg);
writel_relaxed(cd->wakeup_sources[i], reg);
}
@@ -50,17 +55,14 @@ static int gpcv2_wakeup_source_save(void)
 static void gpcv2_wakeup_source_restore(void)
 {
struct gpcv2_irqchip_data *cd;
-   void __iomem *reg;
int i;
 
cd = imx_gpcv2_instance;
if (!cd)
return;
 
-   for (i = 0; i < IMR_NUM; i++) {
-   reg = cd->gpc_base + cd->cpu2wakeup + i * 4;
-   writel_relaxed(cd->saved_irq_mask[i], reg);
-   }
+   for (i = 0; i < IMR_NUM; i++)
+   writel_relaxed(cd->saved_irq_mask[i], gpcv2_idx_to_reg(cd, i));
 }
 
 static struct syscore_ops imx_gpcv2_syscore_ops = {
@@ -97,7 +99,7 @@ static void imx_gpcv2_irq_unmask(struct irq_data *d)
u32 val;
 
raw_spin_lock(>rlock);
-   reg = cd->gpc_base + cd->cpu2wakeup + d->hwirq / 32 * 4;
+   reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
val = readl_relaxed(reg);
val &= ~(1 << d->hwirq % 32);
writel_relaxed(val, reg);
@@ -113,7 +115,7 @@ static void imx_gpcv2_irq_mask(struct irq_data *d)
u32 val;
 
raw_spin_lock(>rlock);
-   reg = cd->gpc_base + cd->cpu2wakeup + d->hwirq / 32 * 4;
+   reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
val = readl_relaxed(reg);
val |= 1 << (d->hwirq % 32);
writel_relaxed(val, reg);
-- 
2.19.1

[PATCH 5/5] irqchip/irq-imx-gpcv2: Add support for i.MX8MQ

[Andrey Smirnov]

Add code needed to support i.MX8MQ.

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index c2b2b3128ddd..17a2dad2d4c2 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -17,6 +17,9 @@
 
 #define GPC_IMR1_CORE0 0x30
 #define GPC_IMR1_CORE1 0x40
+#define GPC_IMR1_CORE2 0x1c0
+#define GPC_IMR1_CORE3 0x1d0
+
 
 struct gpcv2_irqchip_data {
struct raw_spinlock rlock;
@@ -192,11 +195,19 @@ static const struct irq_domain_ops 
gpcv2_irqchip_data_domain_ops = {
.free   = irq_domain_free_irqs_common,
 };
 
+static const struct of_device_id gpcv2_of_match[] = {
+   { .compatible = "fsl,imx7d-gpc",  .data = (const void *) 2 },
+   { .compatible = "fsl,imx8mq-gpc", .data = (const void *) 4 },
+   { /* END */ }
+};
+
 static int __init imx_gpcv2_irqchip_init(struct device_node *node,
   struct device_node *parent)
 {
struct irq_domain *parent_domain, *domain;
struct gpcv2_irqchip_data *cd;
+   const struct of_device_id *id;
+   unsigned long core_num;
int i;
 
if (!parent) {
@@ -204,6 +215,14 @@ static int __init imx_gpcv2_irqchip_init(struct 
device_node *node,
return -ENODEV;
}
 
+   id = of_match_node(gpcv2_of_match, node);
+   if (!id) {
+   pr_err("%pOF: unknown compatibility string\n", node);
+   return -ENODEV;
+   }
+
+   core_num = (unsigned long)id->data;
+
parent_domain = irq_find_host(parent);
if (!parent_domain) {
pr_err("%pOF: unable to get parent domain\n", node);
@@ -236,8 +255,16 @@ static int __init imx_gpcv2_irqchip_init(struct 
device_node *node,
 
/* Initially mask all interrupts */
for (i = 0; i < IMR_NUM; i++) {
-   writel_relaxed(~0, cd->gpc_base + GPC_IMR1_CORE0 + i * 4);
-   writel_relaxed(~0, cd->gpc_base + GPC_IMR1_CORE1 + i * 4);
+   void __iomem *reg = cd->gpc_base + i * 4;
+
+   switch (core_num) {
+   case 4:
+   writel_relaxed(~0, reg + GPC_IMR1_CORE2);
+   writel_relaxed(~0, reg + GPC_IMR1_CORE3);
+   case 2:   /* FALLTHROUGH */
+   writel_relaxed(~0, reg + GPC_IMR1_CORE0);
+   writel_relaxed(~0, reg + GPC_IMR1_CORE1);
+   }
cd->wakeup_sources[i] = ~0;
}
 
-- 
2.19.1

[PATCH 4/5] irqchip/irq-imx-gpcv2: Make error messages more consistent

[Andrey Smirnov]

Make error messages more consistent by making sure each starts with
"%pOF:".

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index 077d56b3183a..c2b2b3128ddd 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -212,7 +212,7 @@ static int __init imx_gpcv2_irqchip_init(struct device_node 
*node,
 
cd = kzalloc(sizeof(struct gpcv2_irqchip_data), GFP_KERNEL);
if (!cd) {
-   pr_err("kzalloc failed!\n");
+   pr_err("%pOF: kzalloc failed!\n", node);
return -ENOMEM;
}
 
@@ -220,7 +220,7 @@ static int __init imx_gpcv2_irqchip_init(struct device_node 
*node,
 
cd->gpc_base = of_iomap(node, 0);
if (!cd->gpc_base) {
-   pr_err("fsl-gpcv2: unable to map gpc registers\n");
+   pr_err("%pOF: unable to map gpc registers\n", node);
kfree(cd);
return -ENOMEM;
}
-- 
2.19.1

[PATCH 5/5] irqchip/irq-imx-gpcv2: Add support for i.MX8MQ

[Andrey Smirnov]

Add code needed to support i.MX8MQ.

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index c2b2b3128ddd..17a2dad2d4c2 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -17,6 +17,9 @@
 
 #define GPC_IMR1_CORE0 0x30
 #define GPC_IMR1_CORE1 0x40
+#define GPC_IMR1_CORE2 0x1c0
+#define GPC_IMR1_CORE3 0x1d0
+
 
 struct gpcv2_irqchip_data {
struct raw_spinlock rlock;
@@ -192,11 +195,19 @@ static const struct irq_domain_ops 
gpcv2_irqchip_data_domain_ops = {
.free   = irq_domain_free_irqs_common,
 };
 
+static const struct of_device_id gpcv2_of_match[] = {
+   { .compatible = "fsl,imx7d-gpc",  .data = (const void *) 2 },
+   { .compatible = "fsl,imx8mq-gpc", .data = (const void *) 4 },
+   { /* END */ }
+};
+
 static int __init imx_gpcv2_irqchip_init(struct device_node *node,
   struct device_node *parent)
 {
struct irq_domain *parent_domain, *domain;
struct gpcv2_irqchip_data *cd;
+   const struct of_device_id *id;
+   unsigned long core_num;
int i;
 
if (!parent) {
@@ -204,6 +215,14 @@ static int __init imx_gpcv2_irqchip_init(struct 
device_node *node,
return -ENODEV;
}
 
+   id = of_match_node(gpcv2_of_match, node);
+   if (!id) {
+   pr_err("%pOF: unknown compatibility string\n", node);
+   return -ENODEV;
+   }
+
+   core_num = (unsigned long)id->data;
+
parent_domain = irq_find_host(parent);
if (!parent_domain) {
pr_err("%pOF: unable to get parent domain\n", node);
@@ -236,8 +255,16 @@ static int __init imx_gpcv2_irqchip_init(struct 
device_node *node,
 
/* Initially mask all interrupts */
for (i = 0; i < IMR_NUM; i++) {
-   writel_relaxed(~0, cd->gpc_base + GPC_IMR1_CORE0 + i * 4);
-   writel_relaxed(~0, cd->gpc_base + GPC_IMR1_CORE1 + i * 4);
+   void __iomem *reg = cd->gpc_base + i * 4;
+
+   switch (core_num) {
+   case 4:
+   writel_relaxed(~0, reg + GPC_IMR1_CORE2);
+   writel_relaxed(~0, reg + GPC_IMR1_CORE3);
+   case 2:   /* FALLTHROUGH */
+   writel_relaxed(~0, reg + GPC_IMR1_CORE0);
+   writel_relaxed(~0, reg + GPC_IMR1_CORE1);
+   }
cd->wakeup_sources[i] = ~0;
}
 
-- 
2.19.1

[PATCH 4/5] irqchip/irq-imx-gpcv2: Make error messages more consistent

[Andrey Smirnov]

Make error messages more consistent by making sure each starts with
"%pOF:".

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index 077d56b3183a..c2b2b3128ddd 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -212,7 +212,7 @@ static int __init imx_gpcv2_irqchip_init(struct device_node 
*node,
 
cd = kzalloc(sizeof(struct gpcv2_irqchip_data), GFP_KERNEL);
if (!cd) {
-   pr_err("kzalloc failed!\n");
+   pr_err("%pOF: kzalloc failed!\n", node);
return -ENOMEM;
}
 
@@ -220,7 +220,7 @@ static int __init imx_gpcv2_irqchip_init(struct device_node 
*node,
 
cd->gpc_base = of_iomap(node, 0);
if (!cd->gpc_base) {
-   pr_err("fsl-gpcv2: unable to map gpc registers\n");
+   pr_err("%pOF: unable to map gpc registers\n", node);
kfree(cd);
return -ENOMEM;
}
-- 
2.19.1

[PATCH 2/5] irqchip/irq-imx-gpcv2: Share reg offset calculation code

[Andrey Smirnov]

Move identical offset calculation code into a small helper function
and make use of it in the rest of the code.

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index cbed00319315..b262ba8b2652 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -28,6 +28,11 @@ struct gpcv2_irqchip_data {
 
 static struct gpcv2_irqchip_data *imx_gpcv2_instance;
 
+static void __iomem *gpcv2_idx_to_reg(struct gpcv2_irqchip_data *cd, int i)
+{
+   return cd->gpc_base + cd->cpu2wakeup + i * 4;
+}
+
 static int gpcv2_wakeup_source_save(void)
 {
struct gpcv2_irqchip_data *cd;
@@ -39,7 +44,7 @@ static int gpcv2_wakeup_source_save(void)
return 0;
 
for (i = 0; i < IMR_NUM; i++) {
-   reg = cd->gpc_base + cd->cpu2wakeup + i * 4;
+   reg = gpcv2_idx_to_reg(cd, i);
cd->saved_irq_mask[i] = readl_relaxed(reg);
writel_relaxed(cd->wakeup_sources[i], reg);
}
@@ -50,17 +55,14 @@ static int gpcv2_wakeup_source_save(void)
 static void gpcv2_wakeup_source_restore(void)
 {
struct gpcv2_irqchip_data *cd;
-   void __iomem *reg;
int i;
 
cd = imx_gpcv2_instance;
if (!cd)
return;
 
-   for (i = 0; i < IMR_NUM; i++) {
-   reg = cd->gpc_base + cd->cpu2wakeup + i * 4;
-   writel_relaxed(cd->saved_irq_mask[i], reg);
-   }
+   for (i = 0; i < IMR_NUM; i++)
+   writel_relaxed(cd->saved_irq_mask[i], gpcv2_idx_to_reg(cd, i));
 }
 
 static struct syscore_ops imx_gpcv2_syscore_ops = {
@@ -97,7 +99,7 @@ static void imx_gpcv2_irq_unmask(struct irq_data *d)
u32 val;
 
raw_spin_lock(>rlock);
-   reg = cd->gpc_base + cd->cpu2wakeup + d->hwirq / 32 * 4;
+   reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
val = readl_relaxed(reg);
val &= ~(1 << d->hwirq % 32);
writel_relaxed(val, reg);
@@ -113,7 +115,7 @@ static void imx_gpcv2_irq_mask(struct irq_data *d)
u32 val;
 
raw_spin_lock(>rlock);
-   reg = cd->gpc_base + cd->cpu2wakeup + d->hwirq / 32 * 4;
+   reg = gpcv2_idx_to_reg(cd, d->hwirq / 32);
val = readl_relaxed(reg);
val |= 1 << (d->hwirq % 32);
writel_relaxed(val, reg);
-- 
2.19.1

[PATCH 0/5] i.MX8MQ support for GPCv2 irqchip driver

[Andrey Smirnov]

Everyone:

This series is 4 trivial (and optional) changes and a patch to add
support for i.MX8MQ to GPCv2 irqchip driver. Bingings for new GPC
variant were taken from [gpcv2-imx8mq]. Hopefully all of the patches
are self-explanatory.

Feedback is welcome!

Thanks,
Andrey Smrinov

[gpcv2-imx8mq] 
https://lore.kernel.org/linux-arm-kernel/20181116154927.16152-3-l.st...@pengutronix.de/

Andrey Smirnov (5):
  irqchip/irq-imx-gpcv2: Remove unused code
  irqchip/irq-imx-gpcv2: Share reg offset calculation code
  irqchip/irq-imx-gpcv2: Make use of BIT() macro
  irqchip/irq-imx-gpcv2: Make error messages more consistent
  irqchip/irq-imx-gpcv2: Add support for i.MX8MQ

 drivers/irqchip/irq-imx-gpcv2.c | 61 -
 1 file changed, 44 insertions(+), 17 deletions(-)

-- 
2.19.1

[PATCH 1/5] irqchip/irq-imx-gpcv2: Remove unused code

[Andrey Smirnov]

Varaible 'reg' in imx_gpcv2_irq_set_wake() has no users. Remove it.

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index 4760307ab43f..cbed00319315 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -73,11 +73,9 @@ static int imx_gpcv2_irq_set_wake(struct irq_data *d, 
unsigned int on)
struct gpcv2_irqchip_data *cd = d->chip_data;
unsigned int idx = d->hwirq / 32;
unsigned long flags;
-   void __iomem *reg;
u32 mask, val;
 
raw_spin_lock_irqsave(>rlock, flags);
-   reg = cd->gpc_base + cd->cpu2wakeup + idx * 4;
mask = 1 << d->hwirq % 32;
val = cd->wakeup_sources[idx];
 
-- 
2.19.1

[PATCH 0/5] i.MX8MQ support for GPCv2 irqchip driver

[Andrey Smirnov]

Everyone:

This series is 4 trivial (and optional) changes and a patch to add
support for i.MX8MQ to GPCv2 irqchip driver. Bingings for new GPC
variant were taken from [gpcv2-imx8mq]. Hopefully all of the patches
are self-explanatory.

Feedback is welcome!

Thanks,
Andrey Smrinov

[gpcv2-imx8mq] 
https://lore.kernel.org/linux-arm-kernel/20181116154927.16152-3-l.st...@pengutronix.de/

Andrey Smirnov (5):
  irqchip/irq-imx-gpcv2: Remove unused code
  irqchip/irq-imx-gpcv2: Share reg offset calculation code
  irqchip/irq-imx-gpcv2: Make use of BIT() macro
  irqchip/irq-imx-gpcv2: Make error messages more consistent
  irqchip/irq-imx-gpcv2: Add support for i.MX8MQ

 drivers/irqchip/irq-imx-gpcv2.c | 61 -
 1 file changed, 44 insertions(+), 17 deletions(-)

-- 
2.19.1

[PATCH 1/5] irqchip/irq-imx-gpcv2: Remove unused code

[Andrey Smirnov]

Varaible 'reg' in imx_gpcv2_irq_set_wake() has no users. Remove it.

Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/irqchip/irq-imx-gpcv2.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index 4760307ab43f..cbed00319315 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -73,11 +73,9 @@ static int imx_gpcv2_irq_set_wake(struct irq_data *d, 
unsigned int on)
struct gpcv2_irqchip_data *cd = d->chip_data;
unsigned int idx = d->hwirq / 32;
unsigned long flags;
-   void __iomem *reg;
u32 mask, val;
 
raw_spin_lock_irqsave(>rlock, flags);
-   reg = cd->gpc_base + cd->cpu2wakeup + idx * 4;
mask = 1 << d->hwirq % 32;
val = cd->wakeup_sources[idx];
 
-- 
2.19.1

linux-next: manual merge of the akpm-current tree with the btrfs-kdave tree

[Stephen Rothwell]

Hi all,

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

  fs/btrfs/extent_io.c

between commit:

  e42c38c80535 ("btrfs: Refactor main loop in extent_readpages")

from the btrfs-kdave tree and commit:

  "fs: don't open code lru_to_page()"

from the akpm-current tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/extent_io.c
index 5104714212b4,3707c95a6598..
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@@ -4103,24 -4103,28 +4103,24 @@@ int extent_readpages(struct address_spa
int nr = 0;
u64 prev_em_start = (u64)-1;
  
 -  for (page_idx = 0; page_idx < nr_pages; page_idx++) {
 -  page = lru_to_page(pages);
 +  while (!list_empty(pages)) {
 +  for (nr = 0; nr < BTRFS_PAGES_BATCH && !list_empty(pages);) {
-   struct page *page = list_entry(pages->prev, struct 
page, lru);
++  struct page *page = lru_to_page(pages);
  
 -  prefetchw(>flags);
 -  list_del(>lru);
 -  if (add_to_page_cache_lru(page, mapping,
 -  page->index,
 -  readahead_gfp_mask(mapping))) {
 -  put_page(page);
 -  continue;
 +  prefetchw(>flags);
 +  list_del(>lru);
 +  if (add_to_page_cache_lru(page, mapping, page->index,
 +  readahead_gfp_mask(mapping))) {
 +  put_page(page);
 +  continue;
 +  }
 +
 +  pagepool[nr++] = page;
}
  
 -  pagepool[nr++] = page;
 -  if (nr < ARRAY_SIZE(pagepool))
 -  continue;
__extent_readpages(tree, pagepool, nr, _cached, ,
 -  _flags, _em_start);
 -  nr = 0;
 + _flags, _em_start);
}
 -  if (nr)
 -  __extent_readpages(tree, pagepool, nr, _cached, ,
 -  _flags, _em_start);
  
if (em_cached)
free_extent_map(em_cached);


pgpc9BWdhrBG6.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the akpm-current tree with the btrfs-kdave tree

[Stephen Rothwell]

Hi all,

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

  fs/btrfs/extent_io.c

between commit:

  e42c38c80535 ("btrfs: Refactor main loop in extent_readpages")

from the btrfs-kdave tree and commit:

  "fs: don't open code lru_to_page()"

from the akpm-current tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/extent_io.c
index 5104714212b4,3707c95a6598..
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@@ -4103,24 -4103,28 +4103,24 @@@ int extent_readpages(struct address_spa
int nr = 0;
u64 prev_em_start = (u64)-1;
  
 -  for (page_idx = 0; page_idx < nr_pages; page_idx++) {
 -  page = lru_to_page(pages);
 +  while (!list_empty(pages)) {
 +  for (nr = 0; nr < BTRFS_PAGES_BATCH && !list_empty(pages);) {
-   struct page *page = list_entry(pages->prev, struct 
page, lru);
++  struct page *page = lru_to_page(pages);
  
 -  prefetchw(>flags);
 -  list_del(>lru);
 -  if (add_to_page_cache_lru(page, mapping,
 -  page->index,
 -  readahead_gfp_mask(mapping))) {
 -  put_page(page);
 -  continue;
 +  prefetchw(>flags);
 +  list_del(>lru);
 +  if (add_to_page_cache_lru(page, mapping, page->index,
 +  readahead_gfp_mask(mapping))) {
 +  put_page(page);
 +  continue;
 +  }
 +
 +  pagepool[nr++] = page;
}
  
 -  pagepool[nr++] = page;
 -  if (nr < ARRAY_SIZE(pagepool))
 -  continue;
__extent_readpages(tree, pagepool, nr, _cached, ,
 -  _flags, _em_start);
 -  nr = 0;
 + _flags, _em_start);
}
 -  if (nr)
 -  __extent_readpages(tree, pagepool, nr, _cached, ,
 -  _flags, _em_start);
  
if (em_cached)
free_extent_map(em_cached);


pgpc9BWdhrBG6.pgp
Description: OpenPGP digital signature

[RFC PATCH RESEND] x86/cpu: Avoid endless loop to get the number of cache leaves

[Pu Wen]

To get the number of cache leaves on AMD or Hygon platform, it should
get the value of cpuid leaf 0x801d. But on certain broken platform
such as a not fullly implemented virtual platform(for example Xen),
the value of the cpuid leaf will nerver be CTYPE_NULL, so the kernel
will run into an endless loop.

To fix this problem, add a new enum type CTYPE_MAX to limit the maximum
cpuid accessing.

Signed-off-by: Pu Wen 
---
 arch/x86/kernel/cpu/cacheinfo.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index dc1b934..7bd167f 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -121,7 +121,8 @@ enum _cache_type {
CTYPE_NULL = 0,
CTYPE_DATA = 1,
CTYPE_INST = 2,
-   CTYPE_UNIFIED = 3
+   CTYPE_UNIFIED = 3,
+   CTYPE_MAX = 4
 };
 
 union _cpuid4_leaf_eax {
@@ -640,7 +641,7 @@ static int find_num_cache_leaves(struct cpuinfo_x86 *c)
/* Do cpuid(op) loop to find out num_cache_leaves */
cpuid_count(op, i, , , , );
cache_eax.full = eax;
-   } while (cache_eax.split.type != CTYPE_NULL);
+   } while (cache_eax.split.type != CTYPE_NULL && i != CTYPE_MAX);
return i;
 }
 
-- 
2.7.4

[RFC PATCH RESEND] x86/cpu: Avoid endless loop to get the number of cache leaves

[Pu Wen]

To get the number of cache leaves on AMD or Hygon platform, it should
get the value of cpuid leaf 0x801d. But on certain broken platform
such as a not fullly implemented virtual platform(for example Xen),
the value of the cpuid leaf will nerver be CTYPE_NULL, so the kernel
will run into an endless loop.

To fix this problem, add a new enum type CTYPE_MAX to limit the maximum
cpuid accessing.

Signed-off-by: Pu Wen 
---
 arch/x86/kernel/cpu/cacheinfo.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index dc1b934..7bd167f 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -121,7 +121,8 @@ enum _cache_type {
CTYPE_NULL = 0,
CTYPE_DATA = 1,
CTYPE_INST = 2,
-   CTYPE_UNIFIED = 3
+   CTYPE_UNIFIED = 3,
+   CTYPE_MAX = 4
 };
 
 union _cpuid4_leaf_eax {
@@ -640,7 +641,7 @@ static int find_num_cache_leaves(struct cpuinfo_x86 *c)
/* Do cpuid(op) loop to find out num_cache_leaves */
cpuid_count(op, i, , , , );
cache_eax.full = eax;
-   } while (cache_eax.split.type != CTYPE_NULL);
+   } while (cache_eax.split.type != CTYPE_NULL && i != CTYPE_MAX);
return i;
 }
 
-- 
2.7.4

Re: [PATCH 4.19 044/110] drm/i915: Disable LP3 watermarks on all SNB machines

[Greg Kroah-Hartman]

On Wed, Dec 05, 2018 at 11:39:05PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 29, 2018 at 03:12:15PM +0100, Greg Kroah-Hartman wrote:
> > 4.19-stable review patch.  If anyone has any objections, please let me know.
> 
> This one apparently introduces some annoying dmesg errors:
> [3.487895] [drm:intel_print_wm_latency [i915]] *ERROR* Primary WM3 
> latency not provided
> [3.487926] [drm:intel_print_wm_latency [i915]] *ERROR* Sprite WM3 latency 
> not provided
> [3.487955] [drm:intel_print_wm_latency [i915]] *ERROR* Cursor WM3 latency 
> not provided
> 
> To silence those please also backport
> commit 274dba1ae8ff ("drm/i915: Downgrade Gen9 Plane WM latency error")

That commit id is not in Linus's tree, are you sure it is correct?

thanks,

greg k-h

Re: [PATCH 4.19 044/110] drm/i915: Disable LP3 watermarks on all SNB machines

[Greg Kroah-Hartman]

On Wed, Dec 05, 2018 at 11:39:05PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 29, 2018 at 03:12:15PM +0100, Greg Kroah-Hartman wrote:
> > 4.19-stable review patch.  If anyone has any objections, please let me know.
> 
> This one apparently introduces some annoying dmesg errors:
> [3.487895] [drm:intel_print_wm_latency [i915]] *ERROR* Primary WM3 
> latency not provided
> [3.487926] [drm:intel_print_wm_latency [i915]] *ERROR* Sprite WM3 latency 
> not provided
> [3.487955] [drm:intel_print_wm_latency [i915]] *ERROR* Cursor WM3 latency 
> not provided
> 
> To silence those please also backport
> commit 274dba1ae8ff ("drm/i915: Downgrade Gen9 Plane WM latency error")

That commit id is not in Linus's tree, are you sure it is correct?

thanks,

greg k-h

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

[Michal Hocko]

On Thu 06-12-18 11:34:30, Pingfan Liu wrote:
[...]
> > I suspect we are looking at two issues here. The first one, and a more
> > important one is that there is a NUMA affinity configured for the device
> > to a non-existing node. The second one is that nr_cpus affects
> > initialization of possible nodes.
> 
> The dev->numa_node info is extracted from acpi table, not depends on
> the instance of numa-node, which may be limited by nr_cpus. Hence the
> node is existing, just not instanced.

Hmm, binding to memory less node is quite dubious. But OK. I am not sure
how much sanitization can we do. We need to fallback anyway so we should
better make sure that all possible nodes are initialized regardless of
nr_cpus. I will look into that.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

[Michal Hocko]

On Thu 06-12-18 11:34:30, Pingfan Liu wrote:
[...]
> > I suspect we are looking at two issues here. The first one, and a more
> > important one is that there is a NUMA affinity configured for the device
> > to a non-existing node. The second one is that nr_cpus affects
> > initialization of possible nodes.
> 
> The dev->numa_node info is extracted from acpi table, not depends on
> the instance of numa-node, which may be limited by nr_cpus. Hence the
> node is existing, just not instanced.

Hmm, binding to memory less node is quite dubious. But OK. I am not sure
how much sanitization can we do. We need to fallback anyway so we should
better make sure that all possible nodes are initialized regardless of
nr_cpus. I will look into that.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] rtc: proc: printf using alarm for alrm

[yuankuiz]

Hi,

Kindly, this format change formats the rtc dump from:
alrm_time   : 00:00:00
alrm_date   : 1970-01-01
alarm_IRQ   : no
alrm_pending: no

to:
alarm time  : 00:00:00
alarm date  : 1970-01-01
alarm IRQ   : no
alarm pending   : no

Thanks,
BR//John Zhao

On 2018-12-04 05:29 PM, yuank...@codeaurora.org wrote:

Hi,

From 549bae59445c5ec67dd6a46f3ea4f58966d40c9b

Current the struct rtc_wkalrm is dumped as
"alrm_" by printing converted from the struct
name of "alrm.*" directly. Shall we use the
"alarm *" to replace the "alrm_*" during this
dumping?

Signed-off-by: John Zhao 
---
 drivers/rtc/rtc-proc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-proc.c b/drivers/rtc/rtc-proc.c
index a9dd921..d4a3c91 100644
--- a/drivers/rtc/rtc-proc.c
+++ b/drivers/rtc/rtc-proc.c
@@ -58,7 +58,7 @@ static int rtc_proc_show(struct seq_file *seq, void 
*offset)


err = rtc_read_alarm(rtc, );
if (err == 0) {
-   seq_printf(seq, "alrm_time\t: ");
+   seq_printf(seq, "alarm time\t: ");
if ((unsigned int)alrm.time.tm_hour <= 24)
seq_printf(seq, "%02d:", alrm.time.tm_hour);
else
@@ -72,7 +72,7 @@ static int rtc_proc_show(struct seq_file *seq, void 
*offset)

else
seq_printf(seq, "**\n");

-   seq_printf(seq, "alrm_date\t: ");
+   seq_printf(seq, "alarm date\t: ");
if ((unsigned int)alrm.time.tm_year <= 200)
seq_printf(seq, "%04d-", alrm.time.tm_year + 1900);
else
@@ -85,9 +85,9 @@ static int rtc_proc_show(struct seq_file *seq, void 
*offset)

seq_printf(seq, "%02d\n", alrm.time.tm_mday);
else
seq_printf(seq, "**\n");
-   seq_printf(seq, "alarm_IRQ\t: %s\n",
+   seq_printf(seq, "alarm IRQ\t: %s\n",
alrm.enabled ? "yes" : "no");
-   seq_printf(seq, "alrm_pending\t: %s\n",
+   seq_printf(seq, "alarm pending\t: %s\n",
alrm.pending ? "yes" : "no");
seq_printf(seq, "update IRQ enabled\t: %s\n",
(rtc->uie_rtctimer.enabled) ? "yes" : "no");

Re: [PATCH] rtc: proc: printf using alarm for alrm

[yuankuiz]

Hi,

Kindly, this format change formats the rtc dump from:
alrm_time   : 00:00:00
alrm_date   : 1970-01-01
alarm_IRQ   : no
alrm_pending: no

to:
alarm time  : 00:00:00
alarm date  : 1970-01-01
alarm IRQ   : no
alarm pending   : no

Thanks,
BR//John Zhao

On 2018-12-04 05:29 PM, yuank...@codeaurora.org wrote:

Hi,

From 549bae59445c5ec67dd6a46f3ea4f58966d40c9b

Current the struct rtc_wkalrm is dumped as
"alrm_" by printing converted from the struct
name of "alrm.*" directly. Shall we use the
"alarm *" to replace the "alrm_*" during this
dumping?

Signed-off-by: John Zhao 
---
 drivers/rtc/rtc-proc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-proc.c b/drivers/rtc/rtc-proc.c
index a9dd921..d4a3c91 100644
--- a/drivers/rtc/rtc-proc.c
+++ b/drivers/rtc/rtc-proc.c
@@ -58,7 +58,7 @@ static int rtc_proc_show(struct seq_file *seq, void 
*offset)


err = rtc_read_alarm(rtc, );
if (err == 0) {
-   seq_printf(seq, "alrm_time\t: ");
+   seq_printf(seq, "alarm time\t: ");
if ((unsigned int)alrm.time.tm_hour <= 24)
seq_printf(seq, "%02d:", alrm.time.tm_hour);
else
@@ -72,7 +72,7 @@ static int rtc_proc_show(struct seq_file *seq, void 
*offset)

else
seq_printf(seq, "**\n");

-   seq_printf(seq, "alrm_date\t: ");
+   seq_printf(seq, "alarm date\t: ");
if ((unsigned int)alrm.time.tm_year <= 200)
seq_printf(seq, "%04d-", alrm.time.tm_year + 1900);
else
@@ -85,9 +85,9 @@ static int rtc_proc_show(struct seq_file *seq, void 
*offset)

seq_printf(seq, "%02d\n", alrm.time.tm_mday);
else
seq_printf(seq, "**\n");
-   seq_printf(seq, "alarm_IRQ\t: %s\n",
+   seq_printf(seq, "alarm IRQ\t: %s\n",
alrm.enabled ? "yes" : "no");
-   seq_printf(seq, "alrm_pending\t: %s\n",
+   seq_printf(seq, "alarm pending\t: %s\n",
alrm.pending ? "yes" : "no");
seq_printf(seq, "update IRQ enabled\t: %s\n",
(rtc->uie_rtctimer.enabled) ? "yes" : "no");

Re: [PATCH 2/2] remoteproc: sysmon: Wait for shutdown-ack/ind on sysmon shutdown

[Bjorn Andersson]

On Tue 20 Nov 13:02 PST 2018, Sibi Sankar wrote:

> After sending a sysmon shutdown request to the SSCTL service on the
> subsystem, wait for the service to send shutdown-ack interrupt or
> an indication message back.
> 

So we get a reply immediate on the shutdown request, and then some time
later we get either an indication or an interrupt to state that it's
actually complete?

> Signed-off-by: Sibi Sankar 
> ---
>  drivers/remoteproc/qcom_sysmon.c | 59 +++-
>  1 file changed, 58 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/qcom_sysmon.c 
> b/drivers/remoteproc/qcom_sysmon.c
[..]
> @@ -283,6 +311,14 @@ static void ssctl_request_shutdown(struct qcom_sysmon 
> *sysmon)
>   dev_err(sysmon->dev, "shutdown request failed\n");
>   else
>   dev_dbg(sysmon->dev, "shutdown request completed\n");
> +
> + if (sysmon->shutdown_irq > 0) {
> + ret = wait_for_completion_timeout(>shutdown_comp,
> +   msecs_to_jiffies(5000));

5 * HZ

> + if (!ret)
> + dev_err(sysmon->dev,
> + "timeout waiting for shutdown ack\n");
> + }
>  }
[..]
> @@ -453,14 +499,25 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc 
> *rproc,
>  
>   sysmon->dev = rproc->dev.parent;
>   sysmon->rproc = rproc;
> + pdev = container_of(sysmon->dev, struct platform_device, dev);
>  
>   sysmon->name = name;
>   sysmon->ssctl_instance = ssctl_instance;
>  
>   init_completion(>comp);
> + init_completion(>shutdown_comp);
>   mutex_init(>lock);
>  
> - ret = qmi_handle_init(>qmi, SSCTL_MAX_MSG_LEN, _ops, 
> NULL);
> + sysmon->shutdown_irq = platform_get_irq_byname(pdev, "shutdown-ack");

Use of_irq_get_byname() on sysmon->dev instead of relying on the fact
that the remoteproc driver is a platform_device.

Also, check and handle the return value - because an EPROBE_DEFER here
will be turned into a -EINVAL by devm_request_threaded_irq().

> + ret = devm_request_threaded_irq(sysmon->dev, sysmon->shutdown_irq,
> + NULL, sysmon_shutdown_interrupt,
> + IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> + "q6v5 shutdown-ack", sysmon);
> + if (ret)
> + dev_err(sysmon->dev, "failed to acquire shutdown-ack IRQ\n");

In the event that sysmon->shutdown_irq is != -ENODATA, you should fail
here.

> +
> + ret = qmi_handle_init(>qmi, SSCTL_MAX_MSG_LEN, _ops,
> +   qmi_indication_handler);

Regards,
Bjorn

Re: [PATCH 2/2] remoteproc: sysmon: Wait for shutdown-ack/ind on sysmon shutdown

[Bjorn Andersson]

On Tue 20 Nov 13:02 PST 2018, Sibi Sankar wrote:

> After sending a sysmon shutdown request to the SSCTL service on the
> subsystem, wait for the service to send shutdown-ack interrupt or
> an indication message back.
> 

So we get a reply immediate on the shutdown request, and then some time
later we get either an indication or an interrupt to state that it's
actually complete?

> Signed-off-by: Sibi Sankar 
> ---
>  drivers/remoteproc/qcom_sysmon.c | 59 +++-
>  1 file changed, 58 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/qcom_sysmon.c 
> b/drivers/remoteproc/qcom_sysmon.c
[..]
> @@ -283,6 +311,14 @@ static void ssctl_request_shutdown(struct qcom_sysmon 
> *sysmon)
>   dev_err(sysmon->dev, "shutdown request failed\n");
>   else
>   dev_dbg(sysmon->dev, "shutdown request completed\n");
> +
> + if (sysmon->shutdown_irq > 0) {
> + ret = wait_for_completion_timeout(>shutdown_comp,
> +   msecs_to_jiffies(5000));

5 * HZ

> + if (!ret)
> + dev_err(sysmon->dev,
> + "timeout waiting for shutdown ack\n");
> + }
>  }
[..]
> @@ -453,14 +499,25 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc 
> *rproc,
>  
>   sysmon->dev = rproc->dev.parent;
>   sysmon->rproc = rproc;
> + pdev = container_of(sysmon->dev, struct platform_device, dev);
>  
>   sysmon->name = name;
>   sysmon->ssctl_instance = ssctl_instance;
>  
>   init_completion(>comp);
> + init_completion(>shutdown_comp);
>   mutex_init(>lock);
>  
> - ret = qmi_handle_init(>qmi, SSCTL_MAX_MSG_LEN, _ops, 
> NULL);
> + sysmon->shutdown_irq = platform_get_irq_byname(pdev, "shutdown-ack");

Use of_irq_get_byname() on sysmon->dev instead of relying on the fact
that the remoteproc driver is a platform_device.

Also, check and handle the return value - because an EPROBE_DEFER here
will be turned into a -EINVAL by devm_request_threaded_irq().

> + ret = devm_request_threaded_irq(sysmon->dev, sysmon->shutdown_irq,
> + NULL, sysmon_shutdown_interrupt,
> + IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> + "q6v5 shutdown-ack", sysmon);
> + if (ret)
> + dev_err(sysmon->dev, "failed to acquire shutdown-ack IRQ\n");

In the event that sysmon->shutdown_irq is != -ENODATA, you should fail
here.

> +
> + ret = qmi_handle_init(>qmi, SSCTL_MAX_MSG_LEN, _ops,
> +   qmi_indication_handler);

Regards,
Bjorn

Re: [PATCH] pinctrl: Use of_node_name_eq for node name comparisons

[Krzysztof Kozlowski]

On Wed, 5 Dec 2018 at 20:51, Rob Herring  wrote:
>
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> Cc: Tomasz Figa 
> Cc: Krzysztof Kozlowski 
> Cc: Sylwester Nawrocki 
> Cc: Linus Walleij 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Krzysztof Kozlowski 

Linus,
I do not have anything queued in pinctrl samsung for next release, so
maybe you could apply this directly?

Best regards,
Krzysztof

Re: [PATCH] pinctrl: Use of_node_name_eq for node name comparisons

[Krzysztof Kozlowski]

On Wed, 5 Dec 2018 at 20:51, Rob Herring  wrote:
>
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> Cc: Tomasz Figa 
> Cc: Krzysztof Kozlowski 
> Cc: Sylwester Nawrocki 
> Cc: Linus Walleij 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Krzysztof Kozlowski 

Linus,
I do not have anything queued in pinctrl samsung for next release, so
maybe you could apply this directly?

Best regards,
Krzysztof

RE: [PATCH v5 0/7] spi: add support for octal mode

[Yogesh Narayan Gaur]

Hi Boris,

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Thursday, December 6, 2018 12:16 PM
> To: Yogesh Narayan Gaur 
> Cc: Vignesh R ; broo...@kernel.org; linux-
> m...@lists.infradead.org; marek.va...@gmail.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; r...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; linux-arm-ker...@lists.infradead.org;
> computersforpe...@gmail.com; frieder.schre...@exceet.de; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v5 0/7] spi: add support for octal mode
> 
> On Thu, 6 Dec 2018 04:20:26 +
> Yogesh Narayan Gaur  wrote:
> 
> > Hi Boris,
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Wednesday, December 5, 2018 6:16 PM
> > > To: Vignesh R ; broo...@kernel.org
> > > Cc: Yogesh Narayan Gaur ; linux-
> > > m...@lists.infradead.org; marek.va...@gmail.com;
> > > linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > > r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > linux-arm-ker...@lists.infradead.org;
> > > computersforpe...@gmail.com; frieder.schre...@exceet.de; linux-
> > > ker...@vger.kernel.org
> > > Subject: Re: [PATCH v5 0/7] spi: add support for octal mode
> > >
> > > On Wed, 5 Dec 2018 17:25:12 +0530
> > > Vignesh R  wrote:
> > >
> > > > >>   mtd: spi-nor: add opcodes for octal Read/Write commands
> > > > >>   mtd: spi-nor: add octal read flag for flash mt35xu512aba
> > > >
> > > > Could you consider merging these two patches alone for v4.21?
> > > > These can be applied independent of other patches in the series
> > > > and would allow supporting OSPI flash at SPI NOR level with Cadence QSPI
> driver.
> > >
> > > Yep, I'll queue them to spi-nor/next.
> > >
> > > > >>   spi: nxp-fspi: add octal mode flag bit for octal support
> > >
> > > Mark, I think you can pick this one too.
> >
> > This patch is dependent on the series [1] which is yet to be applied by you,
> please apply.
> 
> By me? I can't apply SPI patches.

Sorry for ignorance. Did patches needs to be applied by Mark Brown, should I 
resend the patch series again?
Also can you please review the series [1] and add your Reviewed-by tag.

--
Regards
Yogesh Gaur

[1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=76402

RE: [PATCH v5 0/7] spi: add support for octal mode

[Yogesh Narayan Gaur]

Hi Boris,

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Thursday, December 6, 2018 12:16 PM
> To: Yogesh Narayan Gaur 
> Cc: Vignesh R ; broo...@kernel.org; linux-
> m...@lists.infradead.org; marek.va...@gmail.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; r...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; linux-arm-ker...@lists.infradead.org;
> computersforpe...@gmail.com; frieder.schre...@exceet.de; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v5 0/7] spi: add support for octal mode
> 
> On Thu, 6 Dec 2018 04:20:26 +
> Yogesh Narayan Gaur  wrote:
> 
> > Hi Boris,
> >
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Wednesday, December 5, 2018 6:16 PM
> > > To: Vignesh R ; broo...@kernel.org
> > > Cc: Yogesh Narayan Gaur ; linux-
> > > m...@lists.infradead.org; marek.va...@gmail.com;
> > > linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > > r...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > linux-arm-ker...@lists.infradead.org;
> > > computersforpe...@gmail.com; frieder.schre...@exceet.de; linux-
> > > ker...@vger.kernel.org
> > > Subject: Re: [PATCH v5 0/7] spi: add support for octal mode
> > >
> > > On Wed, 5 Dec 2018 17:25:12 +0530
> > > Vignesh R  wrote:
> > >
> > > > >>   mtd: spi-nor: add opcodes for octal Read/Write commands
> > > > >>   mtd: spi-nor: add octal read flag for flash mt35xu512aba
> > > >
> > > > Could you consider merging these two patches alone for v4.21?
> > > > These can be applied independent of other patches in the series
> > > > and would allow supporting OSPI flash at SPI NOR level with Cadence QSPI
> driver.
> > >
> > > Yep, I'll queue them to spi-nor/next.
> > >
> > > > >>   spi: nxp-fspi: add octal mode flag bit for octal support
> > >
> > > Mark, I think you can pick this one too.
> >
> > This patch is dependent on the series [1] which is yet to be applied by you,
> please apply.
> 
> By me? I can't apply SPI patches.

Sorry for ignorance. Did patches needs to be applied by Mark Brown, should I 
resend the patch series again?
Also can you please review the series [1] and add your Reviewed-by tag.

--
Regards
Yogesh Gaur

[1] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=76402

Re: [PATCH v5 0/7] spi: add support for octal mode

[Boris Brezillon]

On Thu, 6 Dec 2018 04:20:26 +
Yogesh Narayan Gaur  wrote:

> Hi Boris,
> 
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, December 5, 2018 6:16 PM
> > To: Vignesh R ; broo...@kernel.org
> > Cc: Yogesh Narayan Gaur ; linux-
> > m...@lists.infradead.org; marek.va...@gmail.com; linux-...@vger.kernel.org;
> > devicet...@vger.kernel.org; r...@kernel.org; mark.rutl...@arm.com;
> > shawn...@kernel.org; linux-arm-ker...@lists.infradead.org;
> > computersforpe...@gmail.com; frieder.schre...@exceet.de; linux-
> > ker...@vger.kernel.org
> > Subject: Re: [PATCH v5 0/7] spi: add support for octal mode
> > 
> > On Wed, 5 Dec 2018 17:25:12 +0530
> > Vignesh R  wrote:
> >   
> > > >>   mtd: spi-nor: add opcodes for octal Read/Write commands
> > > >>   mtd: spi-nor: add octal read flag for flash mt35xu512aba  
> > >
> > > Could you consider merging these two patches alone for v4.21?
> > > These can be applied independent of other patches in the series and
> > > would allow supporting OSPI flash at SPI NOR level with Cadence QSPI 
> > > driver.  
> > 
> > Yep, I'll queue them to spi-nor/next.
> >   
> > > >>   spi: nxp-fspi: add octal mode flag bit for octal support  
> > 
> > Mark, I think you can pick this one too.  
> 
> This patch is dependent on the series [1] which is yet to be applied by you, 
> please apply.

By me? I can't apply SPI patches.

[PATCH v10 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver

[Kulkarni, Ganapatrao]

This patchset adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
The SoC has PMU support in L3 cache controller (L3C) and in the
DDR4 Memory Controller (DMC).

v10:
Updated Documentation patch with comments [6].

[6] https://lkml.org/lkml/2018/12/5/649

v9:
Updated with comments [5].

[5] https://lkml.org/lkml/2018/11/22/517

v8:
Updated with comments [4].

[4] https://lkml.org/lkml/2018/10/25/215

v7:
Incorporated review comments [3].
Modified driver as loadable module.
Updated Documentation with Event description.
Removed per-channel(no SMC calls) sampling implementation(
Since DMC and L3C channels are interleave, we have decided to
sample channel zero and prorate it to account for a Device).

[3] https://patchwork.kernel.org/patch/10479203/

v6:
Rebased to 4.18-rc1
Updated with comments from John Garry[3]

[3] https://lkml.org/lkml/2018/5/17/408

v5:
Incorporated review comments from Mark Rutland[2]
v4:
Incorporated review comments from Mark Rutland[1]

[1] https://www.spinics.net/lists/arm-kernel/msg588563.html
[2] https://lkml.org/lkml/2018/4/26/376

v3:
Fixed warning reported by kbuild robot

v2:
Rebased to 4.12-rc1
Removed Arch VULCAN dependency.
Update SMC call parameters as per latest firmware.

v1:
Initial patch

Ganapatrao Kulkarni (2):
  perf, uncore: Adding documentation for ThunderX2 pmu uncore driver
  ThunderX2, perf : Add Cavium ThunderX2 SoC UNCORE PMU driver

 Documentation/perf/thunderx2-pmu.txt |  93 +++
 drivers/perf/Kconfig |   9 +
 drivers/perf/Makefile|   1 +
 drivers/perf/thunderx2_pmu.c | 861 +++
 include/linux/cpuhotplug.h   |   1 +
 5 files changed, 965 insertions(+)
 create mode 100644 Documentation/perf/thunderx2-pmu.txt
 create mode 100644 drivers/perf/thunderx2_pmu.c

-- 
2.18.0

Re: [PATCH v5 0/7] spi: add support for octal mode

[Boris Brezillon]

On Thu, 6 Dec 2018 04:20:26 +
Yogesh Narayan Gaur  wrote:

> Hi Boris,
> 
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Wednesday, December 5, 2018 6:16 PM
> > To: Vignesh R ; broo...@kernel.org
> > Cc: Yogesh Narayan Gaur ; linux-
> > m...@lists.infradead.org; marek.va...@gmail.com; linux-...@vger.kernel.org;
> > devicet...@vger.kernel.org; r...@kernel.org; mark.rutl...@arm.com;
> > shawn...@kernel.org; linux-arm-ker...@lists.infradead.org;
> > computersforpe...@gmail.com; frieder.schre...@exceet.de; linux-
> > ker...@vger.kernel.org
> > Subject: Re: [PATCH v5 0/7] spi: add support for octal mode
> > 
> > On Wed, 5 Dec 2018 17:25:12 +0530
> > Vignesh R  wrote:
> >   
> > > >>   mtd: spi-nor: add opcodes for octal Read/Write commands
> > > >>   mtd: spi-nor: add octal read flag for flash mt35xu512aba  
> > >
> > > Could you consider merging these two patches alone for v4.21?
> > > These can be applied independent of other patches in the series and
> > > would allow supporting OSPI flash at SPI NOR level with Cadence QSPI 
> > > driver.  
> > 
> > Yep, I'll queue them to spi-nor/next.
> >   
> > > >>   spi: nxp-fspi: add octal mode flag bit for octal support  
> > 
> > Mark, I think you can pick this one too.  
> 
> This patch is dependent on the series [1] which is yet to be applied by you, 
> please apply.

By me? I can't apply SPI patches.

[PATCH v10 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver

[Kulkarni, Ganapatrao]

This patchset adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
The SoC has PMU support in L3 cache controller (L3C) and in the
DDR4 Memory Controller (DMC).

v10:
Updated Documentation patch with comments [6].

[6] https://lkml.org/lkml/2018/12/5/649

v9:
Updated with comments [5].

[5] https://lkml.org/lkml/2018/11/22/517

v8:
Updated with comments [4].

[4] https://lkml.org/lkml/2018/10/25/215

v7:
Incorporated review comments [3].
Modified driver as loadable module.
Updated Documentation with Event description.
Removed per-channel(no SMC calls) sampling implementation(
Since DMC and L3C channels are interleave, we have decided to
sample channel zero and prorate it to account for a Device).

[3] https://patchwork.kernel.org/patch/10479203/

v6:
Rebased to 4.18-rc1
Updated with comments from John Garry[3]

[3] https://lkml.org/lkml/2018/5/17/408

v5:
Incorporated review comments from Mark Rutland[2]
v4:
Incorporated review comments from Mark Rutland[1]

[1] https://www.spinics.net/lists/arm-kernel/msg588563.html
[2] https://lkml.org/lkml/2018/4/26/376

v3:
Fixed warning reported by kbuild robot

v2:
Rebased to 4.12-rc1
Removed Arch VULCAN dependency.
Update SMC call parameters as per latest firmware.

v1:
Initial patch

Ganapatrao Kulkarni (2):
  perf, uncore: Adding documentation for ThunderX2 pmu uncore driver
  ThunderX2, perf : Add Cavium ThunderX2 SoC UNCORE PMU driver

 Documentation/perf/thunderx2-pmu.txt |  93 +++
 drivers/perf/Kconfig |   9 +
 drivers/perf/Makefile|   1 +
 drivers/perf/thunderx2_pmu.c | 861 +++
 include/linux/cpuhotplug.h   |   1 +
 5 files changed, 965 insertions(+)
 create mode 100644 Documentation/perf/thunderx2-pmu.txt
 create mode 100644 drivers/perf/thunderx2_pmu.c

-- 
2.18.0

Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined

[osalvador]

> Btw. the way how we drop all the work on the first page that we
> cannot
> isolate is just goofy. Why don't we simply migrate all that we
> already
> have on the list and go on? Something for a followup cleanup though.

Indeed, that is just wrong.
I will try to send a followup cleanup to fix that.


> Debugged-by: Oscar Salvador 
> Cc: stable
> Signed-off-by: Michal Hocko 

It has been a fun bug to chase down, thanks for the patch ;-)

Reviewed-by: Oscar Salvador 
Tested-by: Oscar Salvador 

Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined

[osalvador]

> Btw. the way how we drop all the work on the first page that we
> cannot
> isolate is just goofy. Why don't we simply migrate all that we
> already
> have on the list and go on? Something for a followup cleanup though.

Indeed, that is just wrong.
I will try to send a followup cleanup to fix that.


> Debugged-by: Oscar Salvador 
> Cc: stable
> Signed-off-by: Michal Hocko 

It has been a fun bug to chase down, thanks for the patch ;-)

Reviewed-by: Oscar Salvador 
Tested-by: Oscar Salvador 

[PATCH v1] dmaengine: imx-sdma: refine to load context only once

[Robin Gong]

The context loaded only one time before channel running,but
currently sdma_config_channel() and dma_prep_* duplicated with
sdma_load_context(), so refine it to load context only one time
before channel running and reload after the channel terminated.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index a2b0a0e..015c17a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -377,6 +377,7 @@ struct sdma_channel {
unsigned long   watermark_level;
u32 shp_addr, per_addr;
enum dma_status status;
+   boolcontext_loaded;
struct imx_dma_data data;
struct work_struct  terminate_worker;
 };
@@ -970,6 +971,9 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int ret;
unsigned long flags;
 
+   if (sdmac->context_loaded)
+   return 0;
+
if (sdmac->direction == DMA_DEV_TO_MEM)
load_address = sdmac->pc_from_device;
else if (sdmac->direction == DMA_DEV_TO_DEV)
@@ -1012,6 +1016,8 @@ static int sdma_load_context(struct sdma_channel *sdmac)
 
spin_unlock_irqrestore(>channel_0_lock, flags);
 
+   sdmac->context_loaded = true;
+
return ret;
 }
 
@@ -1051,6 +1057,7 @@ static void sdma_channel_terminate_work(struct 
work_struct *work)
sdmac->desc = NULL;
spin_unlock_irqrestore(>vc.lock, flags);
vchan_dma_desc_free_list(>vc, );
+   sdmac->context_loaded = false;
 }
 
 static int sdma_disable_channel_async(struct dma_chan *chan)
-- 
2.7.4

[PATCH v1] dmaengine: imx-sdma: refine to load context only once

[Robin Gong]

The context loaded only one time before channel running,but
currently sdma_config_channel() and dma_prep_* duplicated with
sdma_load_context(), so refine it to load context only one time
before channel running and reload after the channel terminated.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index a2b0a0e..015c17a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -377,6 +377,7 @@ struct sdma_channel {
unsigned long   watermark_level;
u32 shp_addr, per_addr;
enum dma_status status;
+   boolcontext_loaded;
struct imx_dma_data data;
struct work_struct  terminate_worker;
 };
@@ -970,6 +971,9 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int ret;
unsigned long flags;
 
+   if (sdmac->context_loaded)
+   return 0;
+
if (sdmac->direction == DMA_DEV_TO_MEM)
load_address = sdmac->pc_from_device;
else if (sdmac->direction == DMA_DEV_TO_DEV)
@@ -1012,6 +1016,8 @@ static int sdma_load_context(struct sdma_channel *sdmac)
 
spin_unlock_irqrestore(>channel_0_lock, flags);
 
+   sdmac->context_loaded = true;
+
return ret;
 }
 
@@ -1051,6 +1057,7 @@ static void sdma_channel_terminate_work(struct 
work_struct *work)
sdmac->desc = NULL;
spin_unlock_irqrestore(>vc.lock, flags);
vchan_dma_desc_free_list(>vc, );
+   sdmac->context_loaded = false;
 }
 
 static int sdma_disable_channel_async(struct dma_chan *chan)
-- 
2.7.4

[PATCH 2/2] iio: accell: mma8452: add optional vcc regulator operation support

[Anson Huang]

The accelerometer's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the mma8451's
power supply is controlled by a GPIO fixed regulator, need to make
sure the regulator is enabled before any communication with mma8451,
this patch adds optional vcc regulator operation support.

Signed-off-by: Anson Huang 
---
 drivers/iio/accel/mma8452.c | 88 +++--
 1 file changed, 86 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 421a0a8..8f6123f 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
@@ -107,6 +108,7 @@ struct mma8452_data {
u8 data_cfg;
const struct mma_chip_info *chip_info;
int sleep_val;
+   struct regulator *vcc_reg;
 };
 
  /**
@@ -1533,6 +1535,14 @@ static int mma8452_probe(struct i2c_client *client,
data->client = client;
mutex_init(>lock);
data->chip_info = match->data;
+   data->vcc_reg = devm_regulator_get_optional(>dev, "vcc");
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_enable(data->vcc_reg);
+   if (ret) {
+   dev_err(>dev, "failed to enable VCC 
regulator\n");
+   return ret;
+   }
+   }
 
ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
if (ret < 0)
@@ -1667,6 +1677,8 @@ static int mma8452_probe(struct i2c_client *client,
 static int mma8452_remove(struct i2c_client *client)
 {
struct iio_dev *indio_dev = i2c_get_clientdata(client);
+   struct mma8452_data *data = iio_priv(indio_dev);
+   int ret;
 
iio_device_unregister(indio_dev);
 
@@ -1678,6 +1690,14 @@ static int mma8452_remove(struct i2c_client *client)
mma8452_trigger_cleanup(indio_dev);
mma8452_standby(iio_priv(indio_dev));
 
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_disable(data->vcc_reg);
+   if (ret) {
+   dev_err(>dev, "failed to disable VCC 
regulator\n");
+   return ret;
+   }
+   }
+
return 0;
 }
 
@@ -1696,6 +1716,14 @@ static int mma8452_runtime_suspend(struct device *dev)
return -EAGAIN;
}
 
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_disable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to disable VCC regulator\n");
+   return ret;
+   }
+   }
+
return 0;
 }
 
@@ -1705,6 +1733,14 @@ static int mma8452_runtime_resume(struct device *dev)
struct mma8452_data *data = iio_priv(indio_dev);
int ret, sleep_val;
 
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_enable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to enable VCC regulator\n");
+   return ret;
+   }
+   }
+
ret = mma8452_active(data);
if (ret < 0)
return ret;
@@ -1723,14 +1759,62 @@ static int mma8452_runtime_resume(struct device *dev)
 #ifdef CONFIG_PM_SLEEP
 static int mma8452_suspend(struct device *dev)
 {
-   return mma8452_standby(iio_priv(i2c_get_clientdata(
+   struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
+   struct mma8452_data *data = iio_priv(indio_dev);
+   int ret;
+
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_enable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to enable VCC regulator\n");
+   return ret;
+   }
+   }
+
+   ret = mma8452_standby(iio_priv(i2c_get_clientdata(
to_i2c_client(dev;
+   if (ret)
+   return ret;
+
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_disable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to disable VCC regulator\n");
+   return ret;
+   }
+   }
+
+   return 0;
 }
 
 static int mma8452_resume(struct device *dev)
 {
-   return mma8452_active(iio_priv(i2c_get_clientdata(
+   struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
+   struct mma8452_data *data = iio_priv(indio_dev);
+   int ret;
+
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_enable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to enable VCC regulator\n");
+   return ret;
+   }
+   }
+
+   ret = mma8452_active(iio_priv(i2c_get_clientdata(
to_i2c_client(dev;
+   if (ret)
+   

[PATCH 2/2] iio: accell: mma8452: add optional vcc regulator operation support

[Anson Huang]

The accelerometer's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the mma8451's
power supply is controlled by a GPIO fixed regulator, need to make
sure the regulator is enabled before any communication with mma8451,
this patch adds optional vcc regulator operation support.

Signed-off-by: Anson Huang 
---
 drivers/iio/accel/mma8452.c | 88 +++--
 1 file changed, 86 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 421a0a8..8f6123f 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MMA8452_STATUS 0x00
 #define  MMA8452_STATUS_DRDY   (BIT(2) | BIT(1) | BIT(0))
@@ -107,6 +108,7 @@ struct mma8452_data {
u8 data_cfg;
const struct mma_chip_info *chip_info;
int sleep_val;
+   struct regulator *vcc_reg;
 };
 
  /**
@@ -1533,6 +1535,14 @@ static int mma8452_probe(struct i2c_client *client,
data->client = client;
mutex_init(>lock);
data->chip_info = match->data;
+   data->vcc_reg = devm_regulator_get_optional(>dev, "vcc");
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_enable(data->vcc_reg);
+   if (ret) {
+   dev_err(>dev, "failed to enable VCC 
regulator\n");
+   return ret;
+   }
+   }
 
ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
if (ret < 0)
@@ -1667,6 +1677,8 @@ static int mma8452_probe(struct i2c_client *client,
 static int mma8452_remove(struct i2c_client *client)
 {
struct iio_dev *indio_dev = i2c_get_clientdata(client);
+   struct mma8452_data *data = iio_priv(indio_dev);
+   int ret;
 
iio_device_unregister(indio_dev);
 
@@ -1678,6 +1690,14 @@ static int mma8452_remove(struct i2c_client *client)
mma8452_trigger_cleanup(indio_dev);
mma8452_standby(iio_priv(indio_dev));
 
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_disable(data->vcc_reg);
+   if (ret) {
+   dev_err(>dev, "failed to disable VCC 
regulator\n");
+   return ret;
+   }
+   }
+
return 0;
 }
 
@@ -1696,6 +1716,14 @@ static int mma8452_runtime_suspend(struct device *dev)
return -EAGAIN;
}
 
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_disable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to disable VCC regulator\n");
+   return ret;
+   }
+   }
+
return 0;
 }
 
@@ -1705,6 +1733,14 @@ static int mma8452_runtime_resume(struct device *dev)
struct mma8452_data *data = iio_priv(indio_dev);
int ret, sleep_val;
 
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_enable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to enable VCC regulator\n");
+   return ret;
+   }
+   }
+
ret = mma8452_active(data);
if (ret < 0)
return ret;
@@ -1723,14 +1759,62 @@ static int mma8452_runtime_resume(struct device *dev)
 #ifdef CONFIG_PM_SLEEP
 static int mma8452_suspend(struct device *dev)
 {
-   return mma8452_standby(iio_priv(i2c_get_clientdata(
+   struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
+   struct mma8452_data *data = iio_priv(indio_dev);
+   int ret;
+
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_enable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to enable VCC regulator\n");
+   return ret;
+   }
+   }
+
+   ret = mma8452_standby(iio_priv(i2c_get_clientdata(
to_i2c_client(dev;
+   if (ret)
+   return ret;
+
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_disable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to disable VCC regulator\n");
+   return ret;
+   }
+   }
+
+   return 0;
 }
 
 static int mma8452_resume(struct device *dev)
 {
-   return mma8452_active(iio_priv(i2c_get_clientdata(
+   struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
+   struct mma8452_data *data = iio_priv(indio_dev);
+   int ret;
+
+   if (!IS_ERR(data->vcc_reg)) {
+   ret = regulator_enable(data->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to enable VCC regulator\n");
+   return ret;
+   }
+   }
+
+   ret = mma8452_active(iio_priv(i2c_get_clientdata(
to_i2c_client(dev;
+   if (ret)
+   

[PATCH 1/2] MAINTAINERS: add gnss scm tree

[Johan Hovold]

Add SCM tree for the gnss subsystem.

Signed-off-by: Johan Hovold 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6682420421c1..03766ddf95a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6316,6 +6316,7 @@ F:include/uapi/linux/gigaset_dev.h
 
 GNSS SUBSYSTEM
 M: Johan Hovold 
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss.git
 S: Maintained
 F: Documentation/ABI/testing/sysfs-class-gnss
 F: Documentation/devicetree/bindings/gnss/
-- 
2.19.2

[PATCH 1/2] MAINTAINERS: add gnss scm tree

[Johan Hovold]

Add SCM tree for the gnss subsystem.

Signed-off-by: Johan Hovold 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6682420421c1..03766ddf95a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6316,6 +6316,7 @@ F:include/uapi/linux/gigaset_dev.h
 
 GNSS SUBSYSTEM
 M: Johan Hovold 
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss.git
 S: Maintained
 F: Documentation/ABI/testing/sysfs-class-gnss
 F: Documentation/devicetree/bindings/gnss/
-- 
2.19.2

[PATCH 2/2] MAINTAINERS: exclude gnss from SIRFPRIMA2 regex matching

[Johan Hovold]

Exclude the gnss subsystem from SIRMPRIMA2 regex matching, which would
otherwise match the unrelated gnss sirf driver.

Cc: Barry Song 
Signed-off-by: Johan Hovold 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 03766ddf95a3..0f083103d625 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1472,6 +1472,7 @@ F:drivers/clk/sirf/
 F: drivers/clocksource/timer-prima2.c
 F: drivers/clocksource/timer-atlas7.c
 N: [^a-z]sirf
+X: drivers/gnss
 
 ARM/EBSA110 MACHINE SUPPORT
 M: Russell King 
-- 
2.19.2

[PATCH 1/2] dt-bindings: iio: accel: mma8452: add optional vcc-supply property

[Anson Huang]

The accelerometer's power supply could be controlled by regulator
on some platforms, add optional property "vcc-supply" to let device
tree to pass phandle to the regulator to driver.

Signed-off-by: Anson Huang 
---
 Documentation/devicetree/bindings/iio/accel/mma8452.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index 2100e9a..410279a 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -20,6 +20,8 @@ Optional properties:
   - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
 interrupt line in use.
 
+  - vcc-supply: phandle to the regulator that provides power to the 
accelerometer.
+
 Example:
 
mma8453fc@1d {
-- 
2.7.4

[PATCH 1/2] dt-bindings: iio: accel: mma8452: add optional vcc-supply property

[Anson Huang]

The accelerometer's power supply could be controlled by regulator
on some platforms, add optional property "vcc-supply" to let device
tree to pass phandle to the regulator to driver.

Signed-off-by: Anson Huang 
---
 Documentation/devicetree/bindings/iio/accel/mma8452.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt 
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index 2100e9a..410279a 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -20,6 +20,8 @@ Optional properties:
   - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
 interrupt line in use.
 
+  - vcc-supply: phandle to the regulator that provides power to the 
accelerometer.
+
 Example:
 
mma8453fc@1d {
-- 
2.7.4

[PATCH 2/2] MAINTAINERS: exclude gnss from SIRFPRIMA2 regex matching

[Johan Hovold]

Exclude the gnss subsystem from SIRMPRIMA2 regex matching, which would
otherwise match the unrelated gnss sirf driver.

Cc: Barry Song 
Signed-off-by: Johan Hovold 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 03766ddf95a3..0f083103d625 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1472,6 +1472,7 @@ F:drivers/clk/sirf/
 F: drivers/clocksource/timer-prima2.c
 F: drivers/clocksource/timer-atlas7.c
 N: [^a-z]sirf
+X: drivers/gnss
 
 ARM/EBSA110 MACHINE SUPPORT
 M: Russell King 
-- 
2.19.2

linux-next: build failure after merge of the device-mapper tree

[Stephen Rothwell]

Hi all,

After merging the device-mapper tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:

In file included from arch/powerpc/include/asm/local.h:144,
 from include/linux/genhd.h:20,
 from block/genhd.c:7:
block/genhd.c: In function 'part_inc_in_flight':
include/linux/percpu-defs.h:219:52: error: invalid operands to binary + (have 
'struct disk_stats' and 'int')
  const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
  ~ ^
include/asm-generic/local.h:31:40: note: in definition of macro 'local_inc'
 #define local_inc(l) atomic_long_inc(&(l)->a)
^
include/linux/percpu-defs.h:259:2: note: in expansion of macro 
'__verify_pcpu_ptr'
  __verify_pcpu_ptr(__p);  \
  ^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:56:13: note: in expansion of macro 'per_cpu_ptr'
  local_inc(_cpu_ptr(part->dkstats, cpu)->in_flight[rw]);
 ^~~
include/linux/percpu-defs.h:260:10: error: invalid type argument of unary '*' 
(have 'struct disk_stats')
  (typeof(*(__p)) __kernel __force *)(__p);   \
  ^~
include/asm-generic/local.h:31:40: note: in definition of macro 'local_inc'
 #define local_inc(l) atomic_long_inc(&(l)->a)
^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:56:13: note: in expansion of macro 'per_cpu_ptr'
  local_inc(_cpu_ptr(part->dkstats, cpu)->in_flight[rw]);
 ^~~
include/linux/percpu-defs.h:219:52: error: invalid operands to binary + (have 
'struct disk_stats' and 'int')
  const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
  ~ ^
include/asm-generic/local.h:31:40: note: in definition of macro 'local_inc'
 #define local_inc(l) atomic_long_inc(&(l)->a)
^
include/linux/percpu-defs.h:259:2: note: in expansion of macro 
'__verify_pcpu_ptr'
  __verify_pcpu_ptr(__p);  \
  ^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:58:14: note: in expansion of macro 'per_cpu_ptr'
   local_inc(_cpu_ptr(part_to_disk(part)->part0.dkstats, 
cpu)->in_flight[rw]);
  ^~~
include/linux/percpu-defs.h:260:10: error: invalid type argument of unary '*' 
(have 'struct disk_stats')
  (typeof(*(__p)) __kernel __force *)(__p);   \
  ^~
include/asm-generic/local.h:31:40: note: in definition of macro 'local_inc'
 #define local_inc(l) atomic_long_inc(&(l)->a)
^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:58:14: note: in expansion of macro 'per_cpu_ptr'
   local_inc(_cpu_ptr(part_to_disk(part)->part0.dkstats, 
cpu)->in_flight[rw]);
  ^~~
block/genhd.c: In function 'part_dec_in_flight':
include/linux/percpu-defs.h:219:52: error: invalid operands to binary + (have 
'struct disk_stats' and 'int')
  const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
  ~ ^
include/asm-generic/local.h:32:40: note: in definition of macro 'local_dec'
 #define local_dec(l) atomic_long_dec(&(l)->a)
^
include/linux/percpu-defs.h:259:2: note: in expansion of macro 
'__verify_pcpu_ptr'
  __verify_pcpu_ptr(__p);  \
  ^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:69:13: note: in expansion of macro 'per_cpu_ptr'
  local_dec(_cpu_ptr(part->dkstats, cpu)->in_flight[rw]);
 ^~~
include/linux/percpu-defs.h:260:10: error: invalid type argument of unary '*' 
(have 'struct disk_stats')
  (typeof(*(__p)) __kernel __force *)(__p);   \
  ^~
include/asm-generic/local.h:32:40: note: in definition of macro 'local_dec'
 #define local_dec(l) atomic_long_dec(&(l)->a)
^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); 

linux-next: build failure after merge of the device-mapper tree

[Stephen Rothwell]

Hi all,

After merging the device-mapper tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:

In file included from arch/powerpc/include/asm/local.h:144,
 from include/linux/genhd.h:20,
 from block/genhd.c:7:
block/genhd.c: In function 'part_inc_in_flight':
include/linux/percpu-defs.h:219:52: error: invalid operands to binary + (have 
'struct disk_stats' and 'int')
  const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
  ~ ^
include/asm-generic/local.h:31:40: note: in definition of macro 'local_inc'
 #define local_inc(l) atomic_long_inc(&(l)->a)
^
include/linux/percpu-defs.h:259:2: note: in expansion of macro 
'__verify_pcpu_ptr'
  __verify_pcpu_ptr(__p);  \
  ^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:56:13: note: in expansion of macro 'per_cpu_ptr'
  local_inc(_cpu_ptr(part->dkstats, cpu)->in_flight[rw]);
 ^~~
include/linux/percpu-defs.h:260:10: error: invalid type argument of unary '*' 
(have 'struct disk_stats')
  (typeof(*(__p)) __kernel __force *)(__p);   \
  ^~
include/asm-generic/local.h:31:40: note: in definition of macro 'local_inc'
 #define local_inc(l) atomic_long_inc(&(l)->a)
^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:56:13: note: in expansion of macro 'per_cpu_ptr'
  local_inc(_cpu_ptr(part->dkstats, cpu)->in_flight[rw]);
 ^~~
include/linux/percpu-defs.h:219:52: error: invalid operands to binary + (have 
'struct disk_stats' and 'int')
  const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
  ~ ^
include/asm-generic/local.h:31:40: note: in definition of macro 'local_inc'
 #define local_inc(l) atomic_long_inc(&(l)->a)
^
include/linux/percpu-defs.h:259:2: note: in expansion of macro 
'__verify_pcpu_ptr'
  __verify_pcpu_ptr(__p);  \
  ^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:58:14: note: in expansion of macro 'per_cpu_ptr'
   local_inc(_cpu_ptr(part_to_disk(part)->part0.dkstats, 
cpu)->in_flight[rw]);
  ^~~
include/linux/percpu-defs.h:260:10: error: invalid type argument of unary '*' 
(have 'struct disk_stats')
  (typeof(*(__p)) __kernel __force *)(__p);   \
  ^~
include/asm-generic/local.h:31:40: note: in definition of macro 'local_inc'
 #define local_inc(l) atomic_long_inc(&(l)->a)
^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:58:14: note: in expansion of macro 'per_cpu_ptr'
   local_inc(_cpu_ptr(part_to_disk(part)->part0.dkstats, 
cpu)->in_flight[rw]);
  ^~~
block/genhd.c: In function 'part_dec_in_flight':
include/linux/percpu-defs.h:219:52: error: invalid operands to binary + (have 
'struct disk_stats' and 'int')
  const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL; \
  ~ ^
include/asm-generic/local.h:32:40: note: in definition of macro 'local_dec'
 #define local_dec(l) atomic_long_dec(&(l)->a)
^
include/linux/percpu-defs.h:259:2: note: in expansion of macro 
'__verify_pcpu_ptr'
  __verify_pcpu_ptr(__p);  \
  ^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); VERIFY_PERCPU_PTR(ptr); })
   ^
block/genhd.c:69:13: note: in expansion of macro 'per_cpu_ptr'
  local_dec(_cpu_ptr(part->dkstats, cpu)->in_flight[rw]);
 ^~~
include/linux/percpu-defs.h:260:10: error: invalid type argument of unary '*' 
(have 'struct disk_stats')
  (typeof(*(__p)) __kernel __force *)(__p);   \
  ^~
include/asm-generic/local.h:32:40: note: in definition of macro 'local_dec'
 #define local_dec(l) atomic_long_dec(&(l)->a)
^
include/linux/percpu-defs.h:263:47: note: in expansion of macro 
'VERIFY_PERCPU_PTR'
 #define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); 

Re: [PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices

[Chunyan Zhang]

On Tue, 4 Dec 2018 at 18:38, Faiz Abbas  wrote:
>
> Hi,
>
> On 04/12/18 12:54 PM, Chunyan Zhang wrote:
> > Some standard SD host controllers can support both external dma
> > controllers as well as ADMA/SDMA in which the SD host controller
> > acts as DMA master. TI's omap controller is the case as an example.
> >
> > Currently the generic SDHCI code supports ADMA/SDMA integrated in
> > the host controller but does not have any support for external DMA
> > controllers implemented using dmaengine, meaning that custom code is
> > needed for any systems that use an external DMA controller with SDHCI.
> >
> ...
>
> > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> > index b001cf4..8e50a97 100644
> > --- a/drivers/mmc/host/sdhci.h
> > +++ b/drivers/mmc/host/sdhci.h
> > @@ -475,6 +475,7 @@ struct sdhci_host {
> >
> >   int irq;/* Device IRQ */
> >   void __iomem *ioaddr;   /* Mapped address */
> > + phys_addr_t mapbase;/* physical address base */
> >   char *bounce_buffer;/* For packing SDMA reads/writes */
> >   dma_addr_t bounce_addr;
> >   unsigned int bounce_buffer_size;
> > @@ -524,6 +525,7 @@ struct sdhci_host {
> >   bool pending_reset; /* Cmd/data reset is pending */
> >   bool irq_wake_enabled;  /* IRQ wakeup is enabled */
> >   bool v4_mode;   /* Host Version 4 Enable */
> > + bool use_external_dma;
> >
> >   struct mmc_request *mrqs_done[SDHCI_MAX_MRQS];  /* Requests done */
> >   struct mmc_command *cmd;/* Current command */
> > @@ -552,6 +554,11 @@ struct sdhci_host {
> >   struct timer_list timer;/* Timer for timeouts */
> >   struct timer_list data_timer;   /* Timer for data timeouts */
> >
> > +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
> > + struct dma_chan *rx_chan;
> > + struct dma_chan *tx_chan;
> > +#endif
> > +
> >   u32 caps;   /* CAPABILITY_0 */
> >   u32 caps1;  /* CAPABILITY_1 */
> >   bool read_caps; /* Capability flags have been read */
> > @@ -785,5 +792,6 @@ void sdhci_start_tuning(struct sdhci_host *host);
> >  void sdhci_end_tuning(struct sdhci_host *host);
> >  void sdhci_reset_tuning(struct sdhci_host *host);
> >  void sdhci_send_tuning(struct sdhci_host *host, u32 opcode);
> > +void sdhci_switch_external_dma(struct sdhci_host *host, bool en);
> >
>
> Can you also add a new attribute in sdhci_host->flags for external dma
> in this file? The log still shows
>
> [3.675028] mmc2: SDHCI controller on 4809c000.mmc [4809c000.mmc]
> using ADMA

Ok, will try to add.

Thanks for your test and review.

Chunyan

>
> when using external dma.
>
> Thanks,
> Faiz

Re: [PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices

[Chunyan Zhang]

On Tue, 4 Dec 2018 at 18:38, Faiz Abbas  wrote:
>
> Hi,
>
> On 04/12/18 12:54 PM, Chunyan Zhang wrote:
> > Some standard SD host controllers can support both external dma
> > controllers as well as ADMA/SDMA in which the SD host controller
> > acts as DMA master. TI's omap controller is the case as an example.
> >
> > Currently the generic SDHCI code supports ADMA/SDMA integrated in
> > the host controller but does not have any support for external DMA
> > controllers implemented using dmaengine, meaning that custom code is
> > needed for any systems that use an external DMA controller with SDHCI.
> >
> ...
>
> > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> > index b001cf4..8e50a97 100644
> > --- a/drivers/mmc/host/sdhci.h
> > +++ b/drivers/mmc/host/sdhci.h
> > @@ -475,6 +475,7 @@ struct sdhci_host {
> >
> >   int irq;/* Device IRQ */
> >   void __iomem *ioaddr;   /* Mapped address */
> > + phys_addr_t mapbase;/* physical address base */
> >   char *bounce_buffer;/* For packing SDMA reads/writes */
> >   dma_addr_t bounce_addr;
> >   unsigned int bounce_buffer_size;
> > @@ -524,6 +525,7 @@ struct sdhci_host {
> >   bool pending_reset; /* Cmd/data reset is pending */
> >   bool irq_wake_enabled;  /* IRQ wakeup is enabled */
> >   bool v4_mode;   /* Host Version 4 Enable */
> > + bool use_external_dma;
> >
> >   struct mmc_request *mrqs_done[SDHCI_MAX_MRQS];  /* Requests done */
> >   struct mmc_command *cmd;/* Current command */
> > @@ -552,6 +554,11 @@ struct sdhci_host {
> >   struct timer_list timer;/* Timer for timeouts */
> >   struct timer_list data_timer;   /* Timer for data timeouts */
> >
> > +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
> > + struct dma_chan *rx_chan;
> > + struct dma_chan *tx_chan;
> > +#endif
> > +
> >   u32 caps;   /* CAPABILITY_0 */
> >   u32 caps1;  /* CAPABILITY_1 */
> >   bool read_caps; /* Capability flags have been read */
> > @@ -785,5 +792,6 @@ void sdhci_start_tuning(struct sdhci_host *host);
> >  void sdhci_end_tuning(struct sdhci_host *host);
> >  void sdhci_reset_tuning(struct sdhci_host *host);
> >  void sdhci_send_tuning(struct sdhci_host *host, u32 opcode);
> > +void sdhci_switch_external_dma(struct sdhci_host *host, bool en);
> >
>
> Can you also add a new attribute in sdhci_host->flags for external dma
> in this file? The log still shows
>
> [3.675028] mmc2: SDHCI controller on 4809c000.mmc [4809c000.mmc]
> using ADMA

Ok, will try to add.

Thanks for your test and review.

Chunyan

>
> when using external dma.
>
> Thanks,
> Faiz

Re: [PATCH] /proc/kpagecount: return 0 for special pages that are never mapped

[Anthony Yznaga]

On 12/05/2018 08:26 PM, Matthew Wilcox wrote:
> On Wed, Dec 05, 2018 at 04:44:15PM -0800, Anthony Yznaga wrote:
>> On 12/05/2018 11:44 AM, Matthew Wilcox wrote:
>>> Nobody seems terribly interested in mapcount overflows.  I got no response
>>> to https://lkml.org/lkml/2018/3/2/991
>> Okay.  Thanks for the background.
>>
>> How about this, then:
> Acked-by: Matthew Wilcox 

Thanks for all of the feedback, Matthew.

Andrew,
Would you like me to submit a revised patch?  An -mm tree diff?

Thanks,
Anthony

Re: [PATCH] /proc/kpagecount: return 0 for special pages that are never mapped

[Anthony Yznaga]

On 12/05/2018 08:26 PM, Matthew Wilcox wrote:
> On Wed, Dec 05, 2018 at 04:44:15PM -0800, Anthony Yznaga wrote:
>> On 12/05/2018 11:44 AM, Matthew Wilcox wrote:
>>> Nobody seems terribly interested in mapcount overflows.  I got no response
>>> to https://lkml.org/lkml/2018/3/2/991
>> Okay.  Thanks for the background.
>>
>> How about this, then:
> Acked-by: Matthew Wilcox 

Thanks for all of the feedback, Matthew.

Andrew,
Would you like me to submit a revised patch?  An -mm tree diff?

Thanks,
Anthony

Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629

[Honghui Zhang]

On Thu, 2018-12-06 at 09:09 +0800, Jianjun Wang wrote:
> MT7629 is an arm platform SoC which has the same PCIe IP with MT7622.
> 
> The read value of BAR0 is 0x_, it's size will be calculated as 4GB
> in arm64 but bogus alignment values at arm32, the pcie device and devices

:s /the pcie device /the bridge device

> behind this bridge will not be enabled. Fix it's BAR0 resource size to
> guarantee the pcie devices will be enabled correctly.
> 
> The HW default value of its device id is invalid, fix it's device id to
> match the hardware implementation.
> 
> Signed-off-by: Jianjun Wang 
> ---
>  drivers/pci/controller/pcie-mediatek.c | 26 ++
>  include/linux/pci_ids.h|  1 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek.c 
> b/drivers/pci/controller/pcie-mediatek.c
> index d20cf461ba00..f8937cc3c87c 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -73,6 +73,7 @@
>  #define PCIE_MSI_VECTOR  0x0c0
>  
>  #define PCIE_CONF_VEND_ID0x100
> +#define PCIE_CONF_DEVICE_ID  0x102
>  #define PCIE_CONF_CLASS_ID   0x106
>  
>  #define PCIE_INT_MASK0x420
> @@ -135,12 +136,14 @@ struct mtk_pcie_port;
>  /**
>   * struct mtk_pcie_soc - differentiate between host generations
>   * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> + * @need_fix_device_id: whether this host's device ID needed to be fixed or 
> not
>   * @ops: pointer to configuration access functions
>   * @startup: pointer to controller setting functions
>   * @setup_irq: pointer to initialize IRQ functions
>   */
>  struct mtk_pcie_soc {
>   bool need_fix_class_id;
> + bool need_fix_device_id;
>   struct pci_ops *ops;
>   int (*startup)(struct mtk_pcie_port *port);
>   int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> @@ -692,6 +695,11 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port 
> *port)
>   writew(val, port->base + PCIE_CONF_CLASS_ID);
>   }
>  
> + if (soc->need_fix_device_id) {
> + val = PCI_DEVICE_ID_MEDIATEK_7629;
> + writew(val, port->base + PCIE_CONF_DEVICE_ID);
> + }
> +
>   /* 100ms timeout value should be enough for Gen1/2 training */
>   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
>!!(val & PCIE_PORT_LINKUP_V2), 20,
> @@ -1238,11 +1246,29 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt7622 
> = {
>   .setup_irq = mtk_pcie_setup_irq,
>  };
>  
> +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> + .need_fix_class_id = true,
> + .need_fix_device_id = true,
> + .ops = _pcie_ops_v2,
> + .startup = mtk_pcie_startup_port_v2,
> + .setup_irq = mtk_pcie_setup_irq,
> +};
> +
> +static void mtk_fixup_bar_size(struct pci_dev *dev)
> +{
> + struct resource *dev_res = >resource[0];
> + /* 32bit resource length will calculate size to 0, set it smaller */
> + dev_res->end = 0xfffe;
> +}

I'm not sure assign the BAR0 size in driver to fit in the bogus
alignment is a good idea. Seems the size value of 0x_fffe also is an
arbitrary value.
Do we have a chance to change the resource framework code to make it
adopt this scenario?

Thanks.

> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MEDIATEK, PCI_DEVICE_ID_MEDIATEK_7629,
> +  mtk_fixup_bar_size);
> +
>  static const struct of_device_id mtk_pcie_ids[] = {
>   { .compatible = "mediatek,mt2701-pcie", .data = _pcie_soc_v1 },
>   { .compatible = "mediatek,mt7623-pcie", .data = _pcie_soc_v1 },
>   { .compatible = "mediatek,mt2712-pcie", .data = _pcie_soc_mt2712 },
>   { .compatible = "mediatek,mt7622-pcie", .data = _pcie_soc_mt7622 },
> + { .compatible = "mediatek,mt7629-pcie", .data = _pcie_soc_mt7629 },
>   {},
>  };
>  
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 69f0abe1ba1a..77b278bac3a8 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2126,6 +2126,7 @@
>  #define PCI_VENDOR_ID_MYRICOM0x14c1
>  
>  #define PCI_VENDOR_ID_MEDIATEK   0x14c3
> +#define PCI_DEVICE_ID_MEDIATEK_7629  0x7629
>  
>  #define PCI_VENDOR_ID_TITAN  0x14D2
>  #define PCI_DEVICE_ID_TITAN_010L 0x8001

Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629

[Honghui Zhang]

On Thu, 2018-12-06 at 09:09 +0800, Jianjun Wang wrote:
> MT7629 is an arm platform SoC which has the same PCIe IP with MT7622.
> 
> The read value of BAR0 is 0x_, it's size will be calculated as 4GB
> in arm64 but bogus alignment values at arm32, the pcie device and devices

:s /the pcie device /the bridge device

> behind this bridge will not be enabled. Fix it's BAR0 resource size to
> guarantee the pcie devices will be enabled correctly.
> 
> The HW default value of its device id is invalid, fix it's device id to
> match the hardware implementation.
> 
> Signed-off-by: Jianjun Wang 
> ---
>  drivers/pci/controller/pcie-mediatek.c | 26 ++
>  include/linux/pci_ids.h|  1 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek.c 
> b/drivers/pci/controller/pcie-mediatek.c
> index d20cf461ba00..f8937cc3c87c 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -73,6 +73,7 @@
>  #define PCIE_MSI_VECTOR  0x0c0
>  
>  #define PCIE_CONF_VEND_ID0x100
> +#define PCIE_CONF_DEVICE_ID  0x102
>  #define PCIE_CONF_CLASS_ID   0x106
>  
>  #define PCIE_INT_MASK0x420
> @@ -135,12 +136,14 @@ struct mtk_pcie_port;
>  /**
>   * struct mtk_pcie_soc - differentiate between host generations
>   * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> + * @need_fix_device_id: whether this host's device ID needed to be fixed or 
> not
>   * @ops: pointer to configuration access functions
>   * @startup: pointer to controller setting functions
>   * @setup_irq: pointer to initialize IRQ functions
>   */
>  struct mtk_pcie_soc {
>   bool need_fix_class_id;
> + bool need_fix_device_id;
>   struct pci_ops *ops;
>   int (*startup)(struct mtk_pcie_port *port);
>   int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> @@ -692,6 +695,11 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port 
> *port)
>   writew(val, port->base + PCIE_CONF_CLASS_ID);
>   }
>  
> + if (soc->need_fix_device_id) {
> + val = PCI_DEVICE_ID_MEDIATEK_7629;
> + writew(val, port->base + PCIE_CONF_DEVICE_ID);
> + }
> +
>   /* 100ms timeout value should be enough for Gen1/2 training */
>   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
>!!(val & PCIE_PORT_LINKUP_V2), 20,
> @@ -1238,11 +1246,29 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt7622 
> = {
>   .setup_irq = mtk_pcie_setup_irq,
>  };
>  
> +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> + .need_fix_class_id = true,
> + .need_fix_device_id = true,
> + .ops = _pcie_ops_v2,
> + .startup = mtk_pcie_startup_port_v2,
> + .setup_irq = mtk_pcie_setup_irq,
> +};
> +
> +static void mtk_fixup_bar_size(struct pci_dev *dev)
> +{
> + struct resource *dev_res = >resource[0];
> + /* 32bit resource length will calculate size to 0, set it smaller */
> + dev_res->end = 0xfffe;
> +}

I'm not sure assign the BAR0 size in driver to fit in the bogus
alignment is a good idea. Seems the size value of 0x_fffe also is an
arbitrary value.
Do we have a chance to change the resource framework code to make it
adopt this scenario?

Thanks.

> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MEDIATEK, PCI_DEVICE_ID_MEDIATEK_7629,
> +  mtk_fixup_bar_size);
> +
>  static const struct of_device_id mtk_pcie_ids[] = {
>   { .compatible = "mediatek,mt2701-pcie", .data = _pcie_soc_v1 },
>   { .compatible = "mediatek,mt7623-pcie", .data = _pcie_soc_v1 },
>   { .compatible = "mediatek,mt2712-pcie", .data = _pcie_soc_mt2712 },
>   { .compatible = "mediatek,mt7622-pcie", .data = _pcie_soc_mt7622 },
> + { .compatible = "mediatek,mt7629-pcie", .data = _pcie_soc_mt7629 },
>   {},
>  };
>  
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 69f0abe1ba1a..77b278bac3a8 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2126,6 +2126,7 @@
>  #define PCI_VENDOR_ID_MYRICOM0x14c1
>  
>  #define PCI_VENDOR_ID_MEDIATEK   0x14c3
> +#define PCI_DEVICE_ID_MEDIATEK_7629  0x7629
>  
>  #define PCI_VENDOR_ID_TITAN  0x14D2
>  #define PCI_DEVICE_ID_TITAN_010L 0x8001