* [PATCH kernel 4/4] KVM: PPC: Propagate errors to the guest when failed instead of ignoring
From: Alexey Kardashevskiy @ 2018-08-30 3:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, David Gibson, kvm-ppc, Paul Mackerras
In-Reply-To: <20180830031647.34134-1-aik@ozlabs.ru>
At the moment if the PUT_TCE{_INDIRECT} handlers fail to update
the hardware tables, we print a warning once, clear the entry and
continue. This is so as at the time the assumption was that if
a VFIO device is hotplugged into the guest, and the userspace replays
virtual DMA mappings (i.e. TCEs) to the hardware tables and if this fails,
then there is nothing useful we can do about it.
However the assumption is not valid as these handlers are not called for
TCE replay (VFIO ioctl interface is used for that) and these handlers
are for new TCEs.
This returns an error to the guest if there is a request which cannot be
processed. By now the only possible failure must be H_TOO_HARD.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/kvm/book3s_64_vio.c | 20 ++++++--------------
arch/powerpc/kvm/book3s_64_vio_hv.c | 20 ++++++--------------
2 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 5cd2a66..5e3151b 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -568,14 +568,10 @@ long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
ret = kvmppc_tce_iommu_map(vcpu->kvm, stt, stit->tbl,
entry, ua, dir);
- if (ret == H_SUCCESS)
- continue;
-
- if (ret == H_TOO_HARD)
+ if (ret != H_SUCCESS) {
+ kvmppc_clear_tce(stit->tbl, entry);
goto unlock_exit;
-
- WARN_ON_ONCE(1);
- kvmppc_clear_tce(stit->tbl, entry);
+ }
}
kvmppc_tce_put(stt, entry, tce);
@@ -660,14 +656,10 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
stit->tbl, entry + i, ua,
iommu_tce_direction(tce));
- if (ret == H_SUCCESS)
- continue;
-
- if (ret == H_TOO_HARD)
+ if (ret != H_SUCCESS) {
+ kvmppc_clear_tce(stit->tbl, entry);
goto unlock_exit;
-
- WARN_ON_ONCE(1);
- kvmppc_clear_tce(stit->tbl, entry);
+ }
}
kvmppc_tce_put(stt, entry + i, tce);
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
index e79ffbb..8d82133 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -380,14 +380,10 @@ long kvmppc_rm_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
ret = kvmppc_rm_tce_iommu_map(vcpu->kvm, stt,
stit->tbl, entry, ua, dir);
- if (ret == H_SUCCESS)
- continue;
-
- if (ret == H_TOO_HARD)
+ if (ret != H_SUCCESS) {
+ kvmppc_rm_clear_tce(stit->tbl, entry);
return ret;
-
- WARN_ON_ONCE_RM(1);
- kvmppc_rm_clear_tce(stit->tbl, entry);
+ }
}
kvmppc_tce_put(stt, entry, tce);
@@ -533,14 +529,10 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
stit->tbl, entry + i, ua,
iommu_tce_direction(tce));
- if (ret == H_SUCCESS)
- continue;
-
- if (ret == H_TOO_HARD)
+ if (ret != H_SUCCESS) {
+ kvmppc_rm_clear_tce(stit->tbl, entry);
goto unlock_exit;
-
- WARN_ON_ONCE_RM(1);
- kvmppc_rm_clear_tce(stit->tbl, entry);
+ }
}
kvmppc_tce_put(stt, entry + i, tce);
--
2.11.0
^ permalink raw reply related
* [PATCH kernel 0/4] KVM: PPC: Some error handling rework
From: Alexey Kardashevskiy @ 2018-08-30 3:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, David Gibson, kvm-ppc, Paul Mackerras
There are some inconsistencies in how I handle errors which prevents
us from validating these properly:
KVM: PPC: Check if IOMMU page is contained in the pinned physical page
KVM: PPC: Book3S: Fix guest DMA when guest partially backed by THP pages
This is based on sha1
ff69279 Ard Biesheuvel "powerpc: disable support for relative ksymtab references".
Please comment. Thanks.
Alexey Kardashevskiy (4):
KVM: PPC: Validate all tces before updating tables
KVM: PPC: Inform the userspace about TCE update failures
KVM: PPC: Validate TCEs against preregistered memory page sizes
KVM: PPC: Propagate errors to the guest when failed instead of
ignoring
arch/powerpc/include/asm/kvm_ppc.h | 2 -
arch/powerpc/kvm/book3s_64_vio.c | 78 ++++++++++++++++++++++++++++---------
arch/powerpc/kvm/book3s_64_vio_hv.c | 60 ++++++++++++++++------------
3 files changed, 96 insertions(+), 44 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH kernel 1/4] KVM: PPC: Validate all tces before updating tables
From: Alexey Kardashevskiy @ 2018-08-30 3:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, David Gibson, kvm-ppc, Paul Mackerras
In-Reply-To: <20180830031647.34134-1-aik@ozlabs.ru>
The KVM TCE handlers are written in a way so they fail when either
something went horribly wrong or the userspace did some obvious mistake
such as passing a misaligned address.
We are going to enhance the TCE checker to fail on attempts to map bigger
IOMMU page than the underlying pinned memory so let's valitate TCE
beforehand.
This should cause no behavioral change.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/kvm/book3s_64_vio.c | 8 ++++++++
arch/powerpc/kvm/book3s_64_vio_hv.c | 4 ++++
2 files changed, 12 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 9a3f264..0fef22b 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -599,6 +599,14 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
ret = kvmppc_tce_validate(stt, tce);
if (ret != H_SUCCESS)
goto unlock_exit;
+ }
+
+ for (i = 0; i < npages; ++i) {
+ if (get_user(tce, tces + i)) {
+ ret = H_TOO_HARD;
+ goto unlock_exit;
+ }
+ tce = be64_to_cpu(tce);
if (kvmppc_gpa_to_ua(vcpu->kvm,
tce & ~(TCE_PCI_READ | TCE_PCI_WRITE),
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
index 506a4d4..7ab6f3f 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -501,6 +501,10 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
ret = kvmppc_tce_validate(stt, tce);
if (ret != H_SUCCESS)
goto unlock_exit;
+ }
+
+ for (i = 0; i < npages; ++i) {
+ unsigned long tce = be64_to_cpu(((u64 *)tces)[i]);
ua = 0;
if (kvmppc_gpa_to_ua(vcpu->kvm,
--
2.11.0
^ permalink raw reply related
* [PATCH kernel 2/4] KVM: PPC: Inform the userspace about TCE update failures
From: Alexey Kardashevskiy @ 2018-08-30 3:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, David Gibson, kvm-ppc, Paul Mackerras
In-Reply-To: <20180830031647.34134-1-aik@ozlabs.ru>
We return H_TOO_HARD from TCE update handlers when we think that
the next handler (realmode -> virtual mode -> user mode) has a chance to
handle the request; H_HARDWARE/H_CLOSED otherwise.
This changes the handlers to return H_TOO_HARD on every error giving
the userspace an opportunity to handle any request or at least log
them all.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/kvm/book3s_64_vio.c | 8 ++++----
arch/powerpc/kvm/book3s_64_vio_hv.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 0fef22b..3e8ac98 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -401,7 +401,7 @@ static long kvmppc_tce_iommu_do_unmap(struct kvm *kvm,
long ret;
if (WARN_ON_ONCE(iommu_tce_xchg(tbl, entry, &hpa, &dir)))
- return H_HARDWARE;
+ return H_TOO_HARD;
if (dir == DMA_NONE)
return H_SUCCESS;
@@ -449,15 +449,15 @@ long kvmppc_tce_iommu_do_map(struct kvm *kvm, struct iommu_table *tbl,
return H_TOO_HARD;
if (WARN_ON_ONCE(mm_iommu_ua_to_hpa(mem, ua, tbl->it_page_shift, &hpa)))
- return H_HARDWARE;
+ return H_TOO_HARD;
if (mm_iommu_mapped_inc(mem))
- return H_CLOSED;
+ return H_TOO_HARD;
ret = iommu_tce_xchg(tbl, entry, &hpa, &dir);
if (WARN_ON_ONCE(ret)) {
mm_iommu_mapped_dec(mem);
- return H_HARDWARE;
+ return H_TOO_HARD;
}
if (dir != DMA_NONE)
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
index 7ab6f3f..9584d9b 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -277,10 +277,10 @@ static long kvmppc_rm_tce_iommu_do_map(struct kvm *kvm, struct iommu_table *tbl,
if (WARN_ON_ONCE_RM(mm_iommu_ua_to_hpa_rm(mem, ua, tbl->it_page_shift,
&hpa)))
- return H_HARDWARE;
+ return H_TOO_HARD;
if (WARN_ON_ONCE_RM(mm_iommu_mapped_inc(mem)))
- return H_CLOSED;
+ return H_TOO_HARD;
ret = iommu_tce_xchg_rm(tbl, entry, &hpa, &dir);
if (ret) {
@@ -478,7 +478,7 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
rmap = (void *) vmalloc_to_phys(rmap);
if (WARN_ON_ONCE_RM(!rmap))
- return H_HARDWARE;
+ return H_TOO_HARD;
/*
* Synchronize with the MMU notifier callbacks in
--
2.11.0
^ permalink raw reply related
* [PATCH kernel 3/4] KVM: PPC: Validate TCEs against preregistered memory page sizes
From: Alexey Kardashevskiy @ 2018-08-30 3:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, David Gibson, kvm-ppc, Paul Mackerras
In-Reply-To: <20180830031647.34134-1-aik@ozlabs.ru>
The userspace can request an arbitrary supported page size for a DMA
window and this works fine as long as the mapped memory is backed with
the pages of the same or bigger size; if this is not the case,
mm_iommu_ua_to_hpa{_rm}() fail and tables do not populated with
dangerously incorrect TCEs.
However since it is quite easy to misconfigure the KVM and we do not do
reverts to all changes made to TCE tables if an error happens in a middle,
we better do the acceptable page size validation before we even touch
the tables.
This enhances kvmppc_tce_validate() to check the hardware IOMMU page sizes
against the preregistered memory page sizes.
Since the new check uses real/virtual mode helpers, this renames
kvmppc_tce_validate() to kvmppc_rm_tce_validate() to handle the real mode
case and mirrors it for the virtual mode under the old name. The real
mode handler is not used for the virtual mode as:
1. it uses _lockless() list traversing primitives instead of RCU;
2. realmode's mm_iommu_ua_to_hpa_rm() uses vmalloc_to_phys() which
virtual mode does not have to use and since on POWER9+radix only virtual
mode handlers actually work, we do not want to slow down that path even
a bit.
This removes EXPORT_SYMBOL_GPL(kvmppc_tce_validate) as the validators
are static now.
>From now on the attempts on mapping IOMMU pages bigger than allowed will
result in KVM exit.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/include/asm/kvm_ppc.h | 2 --
arch/powerpc/kvm/book3s_64_vio.c | 42 +++++++++++++++++++++++++++++++++++++
arch/powerpc/kvm/book3s_64_vio_hv.c | 30 +++++++++++++++++++-------
3 files changed, 65 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index e991821..2f5d431 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -194,8 +194,6 @@ extern struct kvmppc_spapr_tce_table *kvmppc_find_table(
(iommu_tce_check_ioba((stt)->page_shift, (stt)->offset, \
(stt)->size, (ioba), (npages)) ? \
H_PARAMETER : H_SUCCESS)
-extern long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *tt,
- unsigned long tce);
extern long kvmppc_gpa_to_ua(struct kvm *kvm, unsigned long gpa,
unsigned long *ua, unsigned long **prmap);
extern void kvmppc_tce_put(struct kvmppc_spapr_tce_table *tt,
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 3e8ac98..5cd2a66 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -363,6 +363,41 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
return ret;
}
+static long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *stt,
+ unsigned long tce)
+{
+ unsigned long gpa = tce & ~(TCE_PCI_READ | TCE_PCI_WRITE);
+ enum dma_data_direction dir = iommu_tce_direction(tce);
+ struct kvmppc_spapr_tce_iommu_table *stit;
+ unsigned long ua = 0;
+
+ /* Allow userspace to poison TCE table */
+ if (dir == DMA_NONE)
+ return H_SUCCESS;
+
+ if (iommu_tce_check_gpa(stt->page_shift, gpa))
+ return H_TOO_HARD;
+
+ if (kvmppc_gpa_to_ua(stt->kvm, tce & ~(TCE_PCI_READ | TCE_PCI_WRITE),
+ &ua, NULL))
+ return H_TOO_HARD;
+
+ list_for_each_entry_rcu(stit, &stt->iommu_tables, next) {
+ unsigned long hpa = 0;
+ struct mm_iommu_table_group_mem_t *mem;
+ long shift = stit->tbl->it_page_shift;
+
+ mem = mm_iommu_lookup(stt->kvm->mm, ua, 1ULL << shift);
+ if (!mem)
+ return H_TOO_HARD;
+
+ if (mm_iommu_ua_to_hpa(mem, ua, shift, &hpa))
+ return H_TOO_HARD;
+ }
+
+ return H_SUCCESS;
+}
+
static void kvmppc_clear_tce(struct iommu_table *tbl, unsigned long entry)
{
unsigned long hpa = 0;
@@ -602,6 +637,13 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
}
for (i = 0; i < npages; ++i) {
+ /*
+ * This get_user() may produce a different result than few
+ * lines in the validation loop above but we translate it
+ * again little later anyway and if that fails, we simply stop
+ * and return error as it is likely the userspace shooting
+ * itself in a foot.
+ */
if (get_user(tce, tces + i)) {
ret = H_TOO_HARD;
goto unlock_exit;
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
index 9584d9b..e79ffbb 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -94,14 +94,14 @@ EXPORT_SYMBOL_GPL(kvmppc_find_table);
* to the table and user space is supposed to process them), we can skip
* checking other things (such as TCE is a guest RAM address or the page
* was actually allocated).
- *
- * WARNING: This will be called in real-mode on HV KVM and virtual
- * mode on PR KVM
*/
-long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *stt, unsigned long tce)
+static long kvmppc_rm_tce_validate(struct kvmppc_spapr_tce_table *stt,
+ unsigned long tce)
{
unsigned long gpa = tce & ~(TCE_PCI_READ | TCE_PCI_WRITE);
enum dma_data_direction dir = iommu_tce_direction(tce);
+ struct kvmppc_spapr_tce_iommu_table *stit;
+ unsigned long ua = 0;
/* Allow userspace to poison TCE table */
if (dir == DMA_NONE)
@@ -110,9 +110,25 @@ long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *stt, unsigned long tce)
if (iommu_tce_check_gpa(stt->page_shift, gpa))
return H_PARAMETER;
+ if (kvmppc_gpa_to_ua(stt->kvm, tce & ~(TCE_PCI_READ | TCE_PCI_WRITE),
+ &ua, NULL))
+ return H_TOO_HARD;
+
+ list_for_each_entry_lockless(stit, &stt->iommu_tables, next) {
+ unsigned long hpa = 0;
+ struct mm_iommu_table_group_mem_t *mem;
+ long shift = stit->tbl->it_page_shift;
+
+ mem = mm_iommu_lookup_rm(stt->kvm->mm, ua, 1ULL << shift);
+ if (!mem)
+ return H_TOO_HARD;
+
+ if (mm_iommu_ua_to_hpa_rm(mem, ua, shift, &hpa))
+ return H_TOO_HARD;
+ }
+
return H_SUCCESS;
}
-EXPORT_SYMBOL_GPL(kvmppc_tce_validate);
/* Note on the use of page_address() in real mode,
*
@@ -345,7 +361,7 @@ long kvmppc_rm_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
if (ret != H_SUCCESS)
return ret;
- ret = kvmppc_tce_validate(stt, tce);
+ ret = kvmppc_rm_tce_validate(stt, tce);
if (ret != H_SUCCESS)
return ret;
@@ -498,7 +514,7 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
for (i = 0; i < npages; ++i) {
unsigned long tce = be64_to_cpu(((u64 *)tces)[i]);
- ret = kvmppc_tce_validate(stt, tce);
+ ret = kvmppc_rm_tce_validate(stt, tce);
if (ret != H_SUCCESS)
goto unlock_exit;
}
--
2.11.0
^ permalink raw reply related
* Re: Not able to boot cuImage for the target board with MPC8270 processor
From: sgosavi1 @ 2018-08-30 3:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <8ca7e76b239a14e322f00cd1a0eac141472ab2bd.camel@buserror.net>
> Are you sure the device tree you're using is correct for your board,
including
> all addresses being where your U-Boot configured them?
I actually created one for the target board I am using but had similar
problem. So I decided to take the pq2fads.dts tree as a reference since it
is based on the POWER QUICKII family and build the cuImage. I am sure I will
get some errors here but I can debug and then build the device tree for my
board.
I will try to debug the boot wrapper code as suggested. Thanks for your
support.
Sachin.
--
Sent from: http://linuxppc.10917.n7.nabble.com/linuxppc-dev-f3.html
^ permalink raw reply
* Re: [PATCH kernel 1/4] KVM: PPC: Validate all tces before updating tables
From: David Gibson @ 2018-08-30 4:01 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, kvm-ppc, Paul Mackerras
In-Reply-To: <20180830031647.34134-2-aik@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]
On Thu, Aug 30, 2018 at 01:16:44PM +1000, Alexey Kardashevskiy wrote:
> The KVM TCE handlers are written in a way so they fail when either
> something went horribly wrong or the userspace did some obvious mistake
> such as passing a misaligned address.
>
> We are going to enhance the TCE checker to fail on attempts to map bigger
> IOMMU page than the underlying pinned memory so let's valitate TCE
> beforehand.
>
> This should cause no behavioral change.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
With one misgiving..
> ---
> arch/powerpc/kvm/book3s_64_vio.c | 8 ++++++++
> arch/powerpc/kvm/book3s_64_vio_hv.c | 4 ++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
> index 9a3f264..0fef22b 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ -599,6 +599,14 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> ret = kvmppc_tce_validate(stt, tce);
> if (ret != H_SUCCESS)
> goto unlock_exit;
> + }
> +
> + for (i = 0; i < npages; ++i) {
> + if (get_user(tce, tces + i)) {
This looks unsafe, because we validate, then regrab the TCE from
userspace which could have been changed by another thread.
But it actually is safe, because the relevant checks will be
re-executed in the following code. If userspace tries to change this
dodgily it will result in a messier failure mode but won't threaten
the host.
Long term, I think we would be better off copying everything into
kernel space then doing the validation just once. But the difference
should only become apparent with a malicious or badly broken guest,
and in the meantime this series addresses a real problem.
So, I think we should go ahead with it despite that imperfection.
> + ret = H_TOO_HARD;
> + goto unlock_exit;
> + }
> + tce = be64_to_cpu(tce);
>
> if (kvmppc_gpa_to_ua(vcpu->kvm,
> tce & ~(TCE_PCI_READ | TCE_PCI_WRITE),
> diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
> index 506a4d4..7ab6f3f 100644
> --- a/arch/powerpc/kvm/book3s_64_vio_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
> @@ -501,6 +501,10 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> ret = kvmppc_tce_validate(stt, tce);
> if (ret != H_SUCCESS)
> goto unlock_exit;
> + }
> +
> + for (i = 0; i < npages; ++i) {
> + unsigned long tce = be64_to_cpu(((u64 *)tces)[i]);
>
> ua = 0;
> if (kvmppc_gpa_to_ua(vcpu->kvm,
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH kernel 2/4] KVM: PPC: Inform the userspace about TCE update failures
From: David Gibson @ 2018-08-30 4:01 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, kvm-ppc, Paul Mackerras
In-Reply-To: <20180830031647.34134-3-aik@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]
On Thu, Aug 30, 2018 at 01:16:45PM +1000, Alexey Kardashevskiy wrote:
> We return H_TOO_HARD from TCE update handlers when we think that
> the next handler (realmode -> virtual mode -> user mode) has a chance to
> handle the request; H_HARDWARE/H_CLOSED otherwise.
>
> This changes the handlers to return H_TOO_HARD on every error giving
> the userspace an opportunity to handle any request or at least log
> them all.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> arch/powerpc/kvm/book3s_64_vio.c | 8 ++++----
> arch/powerpc/kvm/book3s_64_vio_hv.c | 6 +++---
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
> index 0fef22b..3e8ac98 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ -401,7 +401,7 @@ static long kvmppc_tce_iommu_do_unmap(struct kvm *kvm,
> long ret;
>
> if (WARN_ON_ONCE(iommu_tce_xchg(tbl, entry, &hpa, &dir)))
> - return H_HARDWARE;
> + return H_TOO_HARD;
>
> if (dir == DMA_NONE)
> return H_SUCCESS;
> @@ -449,15 +449,15 @@ long kvmppc_tce_iommu_do_map(struct kvm *kvm, struct iommu_table *tbl,
> return H_TOO_HARD;
>
> if (WARN_ON_ONCE(mm_iommu_ua_to_hpa(mem, ua, tbl->it_page_shift, &hpa)))
> - return H_HARDWARE;
> + return H_TOO_HARD;
>
> if (mm_iommu_mapped_inc(mem))
> - return H_CLOSED;
> + return H_TOO_HARD;
>
> ret = iommu_tce_xchg(tbl, entry, &hpa, &dir);
> if (WARN_ON_ONCE(ret)) {
> mm_iommu_mapped_dec(mem);
> - return H_HARDWARE;
> + return H_TOO_HARD;
> }
>
> if (dir != DMA_NONE)
> diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
> index 7ab6f3f..9584d9b 100644
> --- a/arch/powerpc/kvm/book3s_64_vio_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
> @@ -277,10 +277,10 @@ static long kvmppc_rm_tce_iommu_do_map(struct kvm *kvm, struct iommu_table *tbl,
>
> if (WARN_ON_ONCE_RM(mm_iommu_ua_to_hpa_rm(mem, ua, tbl->it_page_shift,
> &hpa)))
> - return H_HARDWARE;
> + return H_TOO_HARD;
>
> if (WARN_ON_ONCE_RM(mm_iommu_mapped_inc(mem)))
> - return H_CLOSED;
> + return H_TOO_HARD;
>
> ret = iommu_tce_xchg_rm(tbl, entry, &hpa, &dir);
> if (ret) {
> @@ -478,7 +478,7 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
>
> rmap = (void *) vmalloc_to_phys(rmap);
> if (WARN_ON_ONCE_RM(!rmap))
> - return H_HARDWARE;
> + return H_TOO_HARD;
>
> /*
> * Synchronize with the MMU notifier callbacks in
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH kernel 4/4] KVM: PPC: Propagate errors to the guest when failed instead of ignoring
From: David Gibson @ 2018-08-30 4:04 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, kvm-ppc, Paul Mackerras
In-Reply-To: <20180830031647.34134-5-aik@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 3672 bytes --]
On Thu, Aug 30, 2018 at 01:16:47PM +1000, Alexey Kardashevskiy wrote:
> At the moment if the PUT_TCE{_INDIRECT} handlers fail to update
> the hardware tables, we print a warning once, clear the entry and
> continue. This is so as at the time the assumption was that if
> a VFIO device is hotplugged into the guest, and the userspace replays
> virtual DMA mappings (i.e. TCEs) to the hardware tables and if this fails,
> then there is nothing useful we can do about it.
>
> However the assumption is not valid as these handlers are not called for
> TCE replay (VFIO ioctl interface is used for that) and these handlers
> are for new TCEs.
>
> This returns an error to the guest if there is a request which cannot be
> processed. By now the only possible failure must be H_TOO_HARD.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> arch/powerpc/kvm/book3s_64_vio.c | 20 ++++++--------------
> arch/powerpc/kvm/book3s_64_vio_hv.c | 20 ++++++--------------
> 2 files changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
> index 5cd2a66..5e3151b 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ -568,14 +568,10 @@ long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
> ret = kvmppc_tce_iommu_map(vcpu->kvm, stt, stit->tbl,
> entry, ua, dir);
>
> - if (ret == H_SUCCESS)
> - continue;
> -
> - if (ret == H_TOO_HARD)
> + if (ret != H_SUCCESS) {
> + kvmppc_clear_tce(stit->tbl, entry);
> goto unlock_exit;
> -
> - WARN_ON_ONCE(1);
> - kvmppc_clear_tce(stit->tbl, entry);
> + }
> }
>
> kvmppc_tce_put(stt, entry, tce);
> @@ -660,14 +656,10 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> stit->tbl, entry + i, ua,
> iommu_tce_direction(tce));
>
> - if (ret == H_SUCCESS)
> - continue;
> -
> - if (ret == H_TOO_HARD)
> + if (ret != H_SUCCESS) {
> + kvmppc_clear_tce(stit->tbl, entry);
> goto unlock_exit;
> -
> - WARN_ON_ONCE(1);
> - kvmppc_clear_tce(stit->tbl, entry);
> + }
> }
>
> kvmppc_tce_put(stt, entry + i, tce);
> diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
> index e79ffbb..8d82133 100644
> --- a/arch/powerpc/kvm/book3s_64_vio_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
> @@ -380,14 +380,10 @@ long kvmppc_rm_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
> ret = kvmppc_rm_tce_iommu_map(vcpu->kvm, stt,
> stit->tbl, entry, ua, dir);
>
> - if (ret == H_SUCCESS)
> - continue;
> -
> - if (ret == H_TOO_HARD)
> + if (ret != H_SUCCESS) {
> + kvmppc_rm_clear_tce(stit->tbl, entry);
> return ret;
> -
> - WARN_ON_ONCE_RM(1);
> - kvmppc_rm_clear_tce(stit->tbl, entry);
> + }
> }
>
> kvmppc_tce_put(stt, entry, tce);
> @@ -533,14 +529,10 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> stit->tbl, entry + i, ua,
> iommu_tce_direction(tce));
>
> - if (ret == H_SUCCESS)
> - continue;
> -
> - if (ret == H_TOO_HARD)
> + if (ret != H_SUCCESS) {
> + kvmppc_rm_clear_tce(stit->tbl, entry);
> goto unlock_exit;
> -
> - WARN_ON_ONCE_RM(1);
> - kvmppc_rm_clear_tce(stit->tbl, entry);
> + }
> }
>
> kvmppc_tce_put(stt, entry + i, tce);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH kernel 3/4] KVM: PPC: Validate TCEs against preregistered memory page sizes
From: David Gibson @ 2018-08-30 4:03 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: linuxppc-dev, kvm-ppc, Paul Mackerras
In-Reply-To: <20180830031647.34134-4-aik@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 7311 bytes --]
On Thu, Aug 30, 2018 at 01:16:46PM +1000, Alexey Kardashevskiy wrote:
> The userspace can request an arbitrary supported page size for a DMA
> window and this works fine as long as the mapped memory is backed with
> the pages of the same or bigger size; if this is not the case,
> mm_iommu_ua_to_hpa{_rm}() fail and tables do not populated with
> dangerously incorrect TCEs.
>
> However since it is quite easy to misconfigure the KVM and we do not do
> reverts to all changes made to TCE tables if an error happens in a middle,
> we better do the acceptable page size validation before we even touch
> the tables.
>
> This enhances kvmppc_tce_validate() to check the hardware IOMMU page sizes
> against the preregistered memory page sizes.
>
> Since the new check uses real/virtual mode helpers, this renames
> kvmppc_tce_validate() to kvmppc_rm_tce_validate() to handle the real mode
> case and mirrors it for the virtual mode under the old name. The real
> mode handler is not used for the virtual mode as:
> 1. it uses _lockless() list traversing primitives instead of RCU;
> 2. realmode's mm_iommu_ua_to_hpa_rm() uses vmalloc_to_phys() which
> virtual mode does not have to use and since on POWER9+radix only virtual
> mode handlers actually work, we do not want to slow down that path even
> a bit.
>
> This removes EXPORT_SYMBOL_GPL(kvmppc_tce_validate) as the validators
> are static now.
>
> >From now on the attempts on mapping IOMMU pages bigger than allowed will
> result in KVM exit.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> arch/powerpc/include/asm/kvm_ppc.h | 2 --
> arch/powerpc/kvm/book3s_64_vio.c | 42 +++++++++++++++++++++++++++++++++++++
> arch/powerpc/kvm/book3s_64_vio_hv.c | 30 +++++++++++++++++++-------
> 3 files changed, 65 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index e991821..2f5d431 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -194,8 +194,6 @@ extern struct kvmppc_spapr_tce_table *kvmppc_find_table(
> (iommu_tce_check_ioba((stt)->page_shift, (stt)->offset, \
> (stt)->size, (ioba), (npages)) ? \
> H_PARAMETER : H_SUCCESS)
> -extern long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *tt,
> - unsigned long tce);
> extern long kvmppc_gpa_to_ua(struct kvm *kvm, unsigned long gpa,
> unsigned long *ua, unsigned long **prmap);
> extern void kvmppc_tce_put(struct kvmppc_spapr_tce_table *tt,
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
> index 3e8ac98..5cd2a66 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ -363,6 +363,41 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
> return ret;
> }
>
> +static long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *stt,
> + unsigned long tce)
> +{
> + unsigned long gpa = tce & ~(TCE_PCI_READ | TCE_PCI_WRITE);
> + enum dma_data_direction dir = iommu_tce_direction(tce);
> + struct kvmppc_spapr_tce_iommu_table *stit;
> + unsigned long ua = 0;
> +
> + /* Allow userspace to poison TCE table */
> + if (dir == DMA_NONE)
> + return H_SUCCESS;
> +
> + if (iommu_tce_check_gpa(stt->page_shift, gpa))
> + return H_TOO_HARD;
> +
> + if (kvmppc_gpa_to_ua(stt->kvm, tce & ~(TCE_PCI_READ | TCE_PCI_WRITE),
> + &ua, NULL))
> + return H_TOO_HARD;
> +
> + list_for_each_entry_rcu(stit, &stt->iommu_tables, next) {
> + unsigned long hpa = 0;
> + struct mm_iommu_table_group_mem_t *mem;
> + long shift = stit->tbl->it_page_shift;
> +
> + mem = mm_iommu_lookup(stt->kvm->mm, ua, 1ULL << shift);
> + if (!mem)
> + return H_TOO_HARD;
> +
> + if (mm_iommu_ua_to_hpa(mem, ua, shift, &hpa))
> + return H_TOO_HARD;
> + }
> +
> + return H_SUCCESS;
> +}
> +
> static void kvmppc_clear_tce(struct iommu_table *tbl, unsigned long entry)
> {
> unsigned long hpa = 0;
> @@ -602,6 +637,13 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> }
>
> for (i = 0; i < npages; ++i) {
> + /*
> + * This get_user() may produce a different result than few
> + * lines in the validation loop above but we translate it
> + * again little later anyway and if that fails, we simply stop
> + * and return error as it is likely the userspace shooting
> + * itself in a foot.
> + */
> if (get_user(tce, tces + i)) {
> ret = H_TOO_HARD;
> goto unlock_exit;
> diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
> index 9584d9b..e79ffbb 100644
> --- a/arch/powerpc/kvm/book3s_64_vio_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
> @@ -94,14 +94,14 @@ EXPORT_SYMBOL_GPL(kvmppc_find_table);
> * to the table and user space is supposed to process them), we can skip
> * checking other things (such as TCE is a guest RAM address or the page
> * was actually allocated).
> - *
> - * WARNING: This will be called in real-mode on HV KVM and virtual
> - * mode on PR KVM
> */
> -long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *stt, unsigned long tce)
> +static long kvmppc_rm_tce_validate(struct kvmppc_spapr_tce_table *stt,
> + unsigned long tce)
> {
> unsigned long gpa = tce & ~(TCE_PCI_READ | TCE_PCI_WRITE);
> enum dma_data_direction dir = iommu_tce_direction(tce);
> + struct kvmppc_spapr_tce_iommu_table *stit;
> + unsigned long ua = 0;
>
> /* Allow userspace to poison TCE table */
> if (dir == DMA_NONE)
> @@ -110,9 +110,25 @@ long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *stt, unsigned long tce)
> if (iommu_tce_check_gpa(stt->page_shift, gpa))
> return H_PARAMETER;
>
> + if (kvmppc_gpa_to_ua(stt->kvm, tce & ~(TCE_PCI_READ | TCE_PCI_WRITE),
> + &ua, NULL))
> + return H_TOO_HARD;
> +
> + list_for_each_entry_lockless(stit, &stt->iommu_tables, next) {
> + unsigned long hpa = 0;
> + struct mm_iommu_table_group_mem_t *mem;
> + long shift = stit->tbl->it_page_shift;
> +
> + mem = mm_iommu_lookup_rm(stt->kvm->mm, ua, 1ULL << shift);
> + if (!mem)
> + return H_TOO_HARD;
> +
> + if (mm_iommu_ua_to_hpa_rm(mem, ua, shift, &hpa))
> + return H_TOO_HARD;
> + }
> +
> return H_SUCCESS;
> }
> -EXPORT_SYMBOL_GPL(kvmppc_tce_validate);
>
> /* Note on the use of page_address() in real mode,
> *
> @@ -345,7 +361,7 @@ long kvmppc_rm_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
> if (ret != H_SUCCESS)
> return ret;
>
> - ret = kvmppc_tce_validate(stt, tce);
> + ret = kvmppc_rm_tce_validate(stt, tce);
> if (ret != H_SUCCESS)
> return ret;
>
> @@ -498,7 +514,7 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> for (i = 0; i < npages; ++i) {
> unsigned long tce = be64_to_cpu(((u64 *)tces)[i]);
>
> - ret = kvmppc_tce_validate(stt, tce);
> + ret = kvmppc_rm_tce_validate(stt, tce);
> if (ret != H_SUCCESS)
> goto unlock_exit;
> }
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a
From: Vabhav Sharma @ 2018-08-30 7:36 UTC (permalink / raw)
To: Scott Wood, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, mturquette@baylibre.com,
sboyd@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel-owner@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, gregkh@linuxfoundation.org, arnd@arndb.de,
kstewart@linuxfoundation.org, yamada.masahiro@socionext.com
Cc: Yogesh Narayan Gaur, Andy Tang, Udit Kumar, linux@armlinux.org.uk,
Varun Sethi
In-Reply-To: <4a9ea6b451683ec98c92e86a5ae6b91213a6afcf.camel@buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgta2VybmVsLW93
bmVyQHZnZXIua2VybmVsLm9yZyA8bGludXgta2VybmVsLQ0KPiBvd25lckB2Z2VyLmtlcm5lbC5v
cmc+IE9uIEJlaGFsZiBPZiBTY290dCBXb29kDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI5
LCAyMDE4IDU6NDkgQU0NCj4gVG86IFZhYmhhdiBTaGFybWEgPHZhYmhhdi5zaGFybWFAbnhwLmNv
bT47IGxpbnV4LQ0KPiBrZXJuZWxAdmdlci5rZXJuZWwub3JnOyBkZXZpY2V0cmVlQHZnZXIua2Vy
bmVsLm9yZzsgcm9iaCtkdEBrZXJuZWwub3JnOw0KPiBtYXJrLnJ1dGxhbmRAYXJtLmNvbTsgbGlu
dXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LWFybS0NCj4ga2VybmVsQGxpc3RzLmlu
ZnJhZGVhZC5vcmc7IG10dXJxdWV0dGVAYmF5bGlicmUuY29tOyBzYm95ZEBrZXJuZWwub3JnOw0K
PiByandAcmp3eXNvY2tpLm5ldDsgdmlyZXNoLmt1bWFyQGxpbmFyby5vcmc7IGxpbnV4LWNsa0B2
Z2VyLmtlcm5lbC5vcmc7DQo+IGxpbnV4LXBtQHZnZXIua2VybmVsLm9yZzsgbGludXgta2VybmVs
LW93bmVyQHZnZXIua2VybmVsLm9yZzsNCj4gY2F0YWxpbi5tYXJpbmFzQGFybS5jb207IHdpbGwu
ZGVhY29uQGFybS5jb207DQo+IGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3JnOyBhcm5kQGFybmRi
LmRlOw0KPiBrc3Rld2FydEBsaW51eGZvdW5kYXRpb24ub3JnOyB5YW1hZGEubWFzYWhpcm9Ac29j
aW9uZXh0LmNvbQ0KPiBDYzogWW9nZXNoIE5hcmF5YW4gR2F1ciA8eW9nZXNobmFyYXlhbi5nYXVy
QG54cC5jb20+OyBBbmR5IFRhbmcNCj4gPGFuZHkudGFuZ0BueHAuY29tPjsgVWRpdCBLdW1hciA8
dWRpdC5rdW1hckBueHAuY29tPjsNCj4gbGludXhAYXJtbGludXgub3JnLnVrOyBWYXJ1biBTZXRo
aSA8Vi5TZXRoaUBueHAuY29tPg0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDMvNV0gZHJpdmVyczog
Y2xrLXFvcmlxOiBBZGQgY2xvY2tnZW4gc3VwcG9ydCBmb3IgbHgyMTYwYQ0KPiANCj4gT24gTW9u
LCAyMDE4LTA4LTIwIGF0IDEyOjE3ICswNTMwLCBWYWJoYXYgU2hhcm1hIHdyb3RlOg0KPiA+IEZy
b206IFlvZ2VzaCBHYXVyIDx5b2dlc2huYXJheWFuLmdhdXJAbnhwLmNvbT4NCj4gPg0KPiA+IEFk
ZCBjbG9ja2dlbiBzdXBwb3J0IGZvciBseDIxNjBhLg0KPiA+IEFkZGVkIGVudHJ5IGZvciBjb21w
YXQgJ2ZzbCxseDIxNjBhLWNsb2NrZ2VuJy4NCj4gPiBBcyBMWDIxNjBBIGlzIDE2IGNvcmUsIHNv
IG1vZGlmaWVkIHZhbHVlIGZvciBOVU1fQ01VWA0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogVGFu
ZyBZdWFudGlhbiA8YW5keS50YW5nQG54cC5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogWW9nZXNo
IEdhdXIgPHlvZ2VzaG5hcmF5YW4uZ2F1ckBueHAuY29tPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFZh
YmhhdiBTaGFybWEgPHZhYmhhdi5zaGFybWFAbnhwLmNvbT4NCj4gPiAtLS0NCj4gPiAgZHJpdmVy
cy9jbGsvY2xrLXFvcmlxLmMgICAgICAgICB8IDE0ICsrKysrKysrKysrKystDQo+ID4gIGRyaXZl
cnMvY3B1ZnJlcS9xb3JpcS1jcHVmcmVxLmMgfCAgMSArDQo+ID4gIDIgZmlsZXMgY2hhbmdlZCwg
MTQgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2Ry
aXZlcnMvY2xrL2Nsay1xb3JpcS5jIGIvZHJpdmVycy9jbGsvY2xrLXFvcmlxLmMgaW5kZXgNCj4g
PiAzYTE4MTJmLi5mYzZlMzA4IDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMvY2xrL2Nsay1xb3Jp
cS5jDQo+ID4gKysrIGIvZHJpdmVycy9jbGsvY2xrLXFvcmlxLmMNCj4gPiBAQCAtNjAsNyArNjAs
NyBAQCBzdHJ1Y3QgY2xvY2tnZW5fbXV4aW5mbyB7ICB9Ow0KPiA+DQo+ID4gICNkZWZpbmUgTlVN
X0hXQUNDRUwJNQ0KPiA+IC0jZGVmaW5lIE5VTV9DTVVYCTgNCj4gPiArI2RlZmluZSBOVU1fQ01V
WAkxNg0KPiA+DQo+ID4gIHN0cnVjdCBjbG9ja2dlbjsNCj4gPg0KPiA+IEBAIC01NzAsNiArNTcw
LDE3IEBAIHN0YXRpYyBjb25zdCBzdHJ1Y3QgY2xvY2tnZW5fY2hpcGluZm8gY2hpcGluZm9bXSA9
IHsNCj4gPiAgCQkuZmxhZ3MgPSBDR19WRVIzIHwgQ0dfTElUVExFX0VORElBTiwNCj4gPiAgCX0s
DQo+ID4gIAl7DQo+ID4gKwkJLmNvbXBhdCA9ICJmc2wsbHgyMTYwYS1jbG9ja2dlbiIsDQo+ID4g
KwkJLmNtdXhfZ3JvdXBzID0gew0KPiA+ICsJCQkmY2xvY2tnZW4yX2NtdXhfY2dhMTIsICZjbG9j
a2dlbjJfY211eF9jZ2INCj4gPiArCQl9LA0KPiA+ICsJCS5jbXV4X3RvX2dyb3VwID0gew0KPiA+
ICsJCQkwLCAwLCAwLCAwLCAxLCAxLCAxLCAxLCAtMQ0KPiA+ICsJCX0sDQo+ID4gKwkJLnBsbF9t
YXNrID0gMHgzNywNCj4gPiArCQkuZmxhZ3MgPSBDR19WRVIzIHwgQ0dfTElUVExFX0VORElBTiwN
Cj4gPiArCX0sDQo+IA0KPiBXaHkgYXJlIHlvdSBpbmNyZWFzaW5nIE5VTV9DTVVYIGJleW9uZCA4
IGZvciBhIGNoaXAgdGhhdCBvbmx5IGhhcyA4DQo+IGVudHJpZXMgaW4gY211eF90b19ncm91cD8N
CkNvbmZpZ3VyYXRpb24gaXMgMTYgY29yZXMsOCBjbHVzdGVyIHdpdGggMiBjb3JlcyBpbiBlYWNo
IGNsdXN0ZXINCj4gDQo+IC1TY290dA0KDQo=
^ permalink raw reply
* Re: [PATCH 0/9] PCI hotplug diet
From: Andy Shevchenko @ 2018-08-30 8:50 UTC (permalink / raw)
To: Lukas Wunner
Cc: Bjorn Helgaas, linux-pci, okaya, Mika Westerberg, Keith Busch,
Oza Pawandeep, Benjamin Herrenschmidt, Rafael J. Wysocki,
Len Brown, scott, Paul Mackerras, Michael Ellerman, gwshan,
Sebastian Ott, gerald.schaefer, Corentin Chary, Darren Hart,
Andy Shevchenko, Greg Kroah-Hartman, dan.zink, jshah, zubarev,
prarit, ACPI Devel Maling List, linux-s390, Platform Driver,
acpi4asus-user, open list:LINUX FOR POWERPC PA SEMI PWRFICIENT
In-Reply-To: <cover.1534686484.git.lukas@wunner.de>
On Sun, Aug 19, 2018 at 5:35 PM Lukas Wunner <lukas@wunner.de> wrote:
>
> Here's PCI hotplug material I've prepared for v4.20:
>
> Patches [1/9] to [8/9] reduce the code by 488 lines. There should be no
> loss of functionality and no new features, just less and simpler code.
>
> Patch [9/9] collects TODOs for hotplug drivers to spur contributions.
>
>
> I've assumed that my patch "PCI: pciehp: Differentiate between surprise
> and safe removal" (submitted July 31) gets merged before this series:
> https://patchwork.ozlabs.org/patch/951386/
>
> If that patch is not accepted or other pciehp-related patches are merged
> before this series, I'll have to rebase patch [4/9] ("PCI: pciehp: Unify
> controller and slot structs"). No big deal, just a heads-up.
>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
for PDx86 bits
> Thanks,
>
> Lukas
>
>
> Lukas Wunner (9):
> PCI: Simplify disconnected marking
> PCI: pciehp: Drop unnecessary includes
> PCI: pciehp: Drop hotplug_slot_ops wrappers
> PCI: pciehp: Unify controller and slot structs
> PCI: pciehp: Reshuffle controller struct for clarity
> PCI: hotplug: Constify hotplug_slot_ops
> PCI: hotplug: Drop hotplug_slot_info
> PCI: hotplug: Embed hotplug_slot
> PCI: hotplug: Document TODOs
>
> arch/powerpc/include/asm/pnv-pci.h | 2 +-
> drivers/pci/hotplug/TODO | 74 +++++++
> drivers/pci/hotplug/acpiphp.h | 10 +-
> drivers/pci/hotplug/acpiphp_core.c | 36 +---
> drivers/pci/hotplug/acpiphp_ibm.c | 2 +-
> drivers/pci/hotplug/cpci_hotplug.h | 11 +-
> drivers/pci/hotplug/cpci_hotplug_core.c | 105 +++-------
> drivers/pci/hotplug/cpci_hotplug_pci.c | 6 +-
> drivers/pci/hotplug/cpqphp.h | 9 +-
> drivers/pci/hotplug/cpqphp_core.c | 59 ++----
> drivers/pci/hotplug/cpqphp_ctrl.c | 31 +--
> drivers/pci/hotplug/ibmphp.h | 9 +-
> drivers/pci/hotplug/ibmphp_core.c | 121 ++++-------
> drivers/pci/hotplug/ibmphp_ebda.c | 70 +------
> drivers/pci/hotplug/pci_hotplug_core.c | 53 ++---
> drivers/pci/hotplug/pciehp.h | 138 ++++++-------
> drivers/pci/hotplug/pciehp_core.c | 127 +++---------
> drivers/pci/hotplug/pciehp_ctrl.c | 255 +++++++++++-------------
> drivers/pci/hotplug/pciehp_hpc.c | 127 ++++--------
> drivers/pci/hotplug/pciehp_pci.c | 24 +--
> drivers/pci/hotplug/pnv_php.c | 35 ++--
> drivers/pci/hotplug/rpaphp.h | 10 +-
> drivers/pci/hotplug/rpaphp_core.c | 20 +-
> drivers/pci/hotplug/rpaphp_pci.c | 11 +-
> drivers/pci/hotplug/rpaphp_slot.c | 22 +-
> drivers/pci/hotplug/s390_pci_hpc.c | 44 ++--
> drivers/pci/hotplug/sgi_hotplug.c | 63 +++---
> drivers/pci/hotplug/shpchp.h | 8 +-
> drivers/pci/hotplug/shpchp_core.c | 48 ++---
> drivers/pci/hotplug/shpchp_ctrl.c | 21 +-
> drivers/pci/pci.c | 4 +-
> drivers/pci/pcie/err.c | 8 +-
> drivers/pci/slot.c | 2 +-
> drivers/platform/x86/asus-wmi.c | 39 +---
> drivers/platform/x86/eeepc-laptop.c | 43 ++--
> include/linux/pci_hotplug.h | 43 +---
> 36 files changed, 638 insertions(+), 1052 deletions(-)
> create mode 100644 drivers/pci/hotplug/TODO
>
> --
> 2.18.0
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 2/2] usb: gadget: fsl_udc_core: fixup struct_udc_setup documentation
From: Nicholas Mc Guire @ 2018-08-30 10:16 UTC (permalink / raw)
To: Li Yang
Cc: Felipe Balbi, Greg Kroah-Hartman, linux-usb, linuxppc-dev,
linux-kernel, Nicholas Mc Guire
In-Reply-To: <1535624219-17854-1-git-send-email-hofrat@osadl.org>
The original implementation from commit b504882da539
("USB: add Freescale high-speed USB SOC device controller driver")
returned NULL on failure and an allocated + initialized struct fsl_udc on
success. The current code introduced in commit 4365831dadfe
("USB: fsl_usb2_udc: Get max ep number from DCCPARAMS register") only
provides partial initialization as well as returning 0 on success and -1
on failures. The function documentation is updated accordingly.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes: 4365831dadfe ("USB: fsl_usb2_udc: Get max ep number from DCCPARAMS register")
---
Problem located during code-review
Patch is against 4.19-rc1 (localversion-next is next-20180830)
drivers/usb/gadget/udc/fsl_udc_core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
index e637afb..680b46e 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2234,8 +2234,10 @@ static void fsl_udc_release(struct device *dev)
Internal structure setup functions
*******************************************************************/
/*------------------------------------------------------------------
- * init resource for globle controller
- * Return the udc handle on success or NULL on failure
+ * init resource for global controller called by fsl_udc_probe()
+ * On success the udc handle is initialized, on failure it is
+ * unchanged (reset).
+ * Return 0 on success and -1 on allocation failure
------------------------------------------------------------------*/
static int struct_udc_setup(struct fsl_udc *udc,
struct platform_device *pdev)
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] usb: gadget: fsl_udc_core: check allocation return value and cleanup on failure
From: Nicholas Mc Guire @ 2018-08-30 10:16 UTC (permalink / raw)
To: Li Yang
Cc: Felipe Balbi, Greg Kroah-Hartman, linux-usb, linuxppc-dev,
linux-kernel, Nicholas Mc Guire
The allocation with fsl_alloc_request() and kmalloc() were unchecked
fixed this up with a NULL check and appropriate cleanup.
Additionally udc->ep_qh_size was reset to 0 on failure of allocation.
Similar udc->phy_mode is initially 0 (as udc_controller was
allocated with kzalloc in fsl_udc_probe()) so reset it to 0 as well
so that this function is side-effect free on failure. Not clear if
this is necessary or sensible as fsl_udc_release() probably can not
be called if fsl_udc_probe() failed - but it should not hurt.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes: b504882da5 ("USB: add Freescale high-speed USB SOC device controller driver")
---
Problem located with experimental coccinelle script
Patch was compile tested with: imx_v6_v7_defconfig (implies USB_FSL_USB2=y)
(with a large number of sparse warnings not related to the proposed change
and one smatch warning)
Patch is against 4.19-rc1 (localversion-next is next-20180830)
drivers/usb/gadget/udc/fsl_udc_core.c | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
index be59309..e637afb 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2247,8 +2247,10 @@ static int struct_udc_setup(struct fsl_udc *udc,
udc->phy_mode = pdata->phy_mode;
udc->eps = kcalloc(udc->max_ep, sizeof(struct fsl_ep), GFP_KERNEL);
- if (!udc->eps)
- return -1;
+ if (!udc->eps) {
+ ERR("kmalloc udc endpoint status failed\n");
+ goto eps_alloc_failed;
+ }
/* initialized QHs, take care of alignment */
size = udc->max_ep * sizeof(struct ep_queue_head);
@@ -2262,8 +2264,7 @@ static int struct_udc_setup(struct fsl_udc *udc,
&udc->ep_qh_dma, GFP_KERNEL);
if (!udc->ep_qh) {
ERR("malloc QHs for udc failed\n");
- kfree(udc->eps);
- return -1;
+ goto ep_queue_alloc_failed;
}
udc->ep_qh_size = size;
@@ -2272,8 +2273,17 @@ static int struct_udc_setup(struct fsl_udc *udc,
/* FIXME: fsl_alloc_request() ignores ep argument */
udc->status_req = container_of(fsl_alloc_request(NULL, GFP_KERNEL),
struct fsl_req, req);
+ if (!udc->status_req) {
+ ERR("kzalloc for udc status request failed\n");
+ goto udc_status_alloc_failed;
+ }
+
/* allocate a small amount of memory to get valid address */
udc->status_req->req.buf = kmalloc(8, GFP_KERNEL);
+ if (!udc->status_req->req.buf) {
+ ERR("kzalloc for udc request buffer failed\n");
+ goto udc_req_buf_alloc_failed;
+ }
udc->resume_state = USB_STATE_NOTATTACHED;
udc->usb_state = USB_STATE_POWERED;
@@ -2281,6 +2291,18 @@ static int struct_udc_setup(struct fsl_udc *udc,
udc->remote_wakeup = 0; /* default to 0 on reset */
return 0;
+
+udc_req_buf_alloc_failed:
+ kfree(udc->status_req);
+udc_status_alloc_failed:
+ kfree(udc->ep_qh);
+ udc->ep_qh_size = 0;
+ep_queue_alloc_failed:
+ kfree(udc->eps);
+eps_alloc_failed:
+ udc->phy_mode = 0;
+ return -1;
+
}
/*----------------------------------------------------------------
--
2.1.4
^ permalink raw reply related
* Re: [PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock
From: David Hildenbrand @ 2018-08-30 12:31 UTC (permalink / raw)
To: linux-mm
Cc: linux-kernel, linux-doc, linuxppc-dev, linux-acpi, xen-devel,
devel, Andrew Morton, Balbir Singh, Benjamin Herrenschmidt,
Boris Ostrovsky, Dan Williams, Greg Kroah-Hartman, Haiyang Zhang,
Heiko Carstens, John Allen, Jonathan Corbet, Joonsoo Kim,
Juergen Gross, Kate Stewart, K. Y. Srinivasan, Len Brown,
Martin Schwidefsky, Mathieu Malaterre, Michael Ellerman,
Michael Neuling, Michal Hocko, Nathan Fontenot, Oscar Salvador,
Paul Mackerras, Pavel Tatashin, Philippe Ombredanne,
Rafael J. Wysocki, Rashmica Gupta, Stephen Hemminger,
Thomas Gleixner, Vlastimil Babka, YASUAKI ISHIMATSU
In-Reply-To: <20180821104418.12710-1-david@redhat.com>
On 21.08.2018 12:44, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
>
I'll be on vacation for two weeks starting on Saturday. If there are no
comments I'll send this as !RFC once I return.
Thanks!
> --------------------------------------------------------------------------
>
> Reading through the code and studying how mem_hotplug_lock is to be used,
> I noticed that there are two places where we can end up calling
> device_online()/device_offline() - online_pages()/offline_pages() without
> the mem_hotplug_lock. And there are other places where we call
> device_online()/device_offline() without the device_hotplug_lock.
>
> While e.g.
> echo "online" > /sys/devices/system/memory/memory9/state
> is fine, e.g.
> echo 1 > /sys/devices/system/memory/memory9/online
> Will not take the mem_hotplug_lock. However the device_lock() and
> device_hotplug_lock.
>
> E.g. via memory_probe_store(), we can end up calling
> add_memory()->online_pages() without the device_hotplug_lock. So we can
> have concurrent callers in online_pages(). We e.g. touch in online_pages()
> basically unprotected zone->present_pages then.
>
> Looks like there is a longer history to that (see Patch #2 for details),
> and fixing it to work the way it was intended is not really possible. We
> would e.g. have to take the mem_hotplug_lock in device/base/core.c, which
> sounds wrong.
>
> Summary: We had a lock inversion on mem_hotplug_lock and device_lock().
> More details can be found in patch 3 and patch 6.
>
> I propose the general rules (documentation added in patch 6):
>
> 1. add_memory/add_memory_resource() must only be called with
> device_hotplug_lock.
> 2. remove_memory() must only be called with device_hotplug_lock. This is
> already documented and holds for all callers.
> 3. device_online()/device_offline() must only be called with
> device_hotplug_lock. This is already documented and true for now in core
> code. Other callers (related to memory hotplug) have to be fixed up.
> 4. mem_hotplug_lock is taken inside of add_memory/remove_memory/
> online_pages/offline_pages.
>
> To me, this looks way cleaner than what we have right now (and easier to
> verify). And looking at the documentation of remove_memory, using
> lock_device_hotplug also for add_memory() feels natural.
>
>
> RFC -> RFCv2:
> - Don't export device_hotplug_lock, provide proper remove_memory/add_memory
> wrappers.
> - Split up the patches a bit.
> - Try to improve powernv memtrace locking
> - Add some documentation for locking that matches my knowledge
>
> David Hildenbrand (6):
> mm/memory_hotplug: make remove_memory() take the device_hotplug_lock
> mm/memory_hotplug: make add_memory() take the device_hotplug_lock
> mm/memory_hotplug: fix online/offline_pages called w.o.
> mem_hotplug_lock
> powerpc/powernv: hold device_hotplug_lock when calling device_online()
> powerpc/powernv: hold device_hotplug_lock in memtrace_offline_pages()
> memory-hotplug.txt: Add some details about locking internals
>
> Documentation/memory-hotplug.txt | 39 +++++++++++-
> arch/powerpc/platforms/powernv/memtrace.c | 14 +++--
> .../platforms/pseries/hotplug-memory.c | 8 +--
> drivers/acpi/acpi_memhotplug.c | 4 +-
> drivers/base/memory.c | 22 +++----
> drivers/xen/balloon.c | 3 +
> include/linux/memory_hotplug.h | 4 +-
> mm/memory_hotplug.c | 59 +++++++++++++++----
> 8 files changed, 115 insertions(+), 38 deletions(-)
>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v1] mm: relax deferred struct page requirements
From: Pasha Tatashin @ 2018-08-30 14:35 UTC (permalink / raw)
To: Jiri Slaby
Cc: mhocko@kernel.org, Steven Sistare, Daniel Jordan,
benh@kernel.crashing.org, paulus@samba.org, Andrew Morton,
kirill.shutemov@linux.intel.com, Reza Arbab,
schwidefsky@de.ibm.com, Heiko Carstens, x86@kernel.org, LKML,
tglx@linutronix.de, linuxppc-dev@lists.ozlabs.org,
Linux Memory Management List, linux-s390@vger.kernel.org,
mgorman@techsingularity.net
In-Reply-To: <c4d46b63-5237-d002-faf5-4e0749d825d7@suse.cz>
VGhhbmsgeW91IEppcmksIEkgYW0gc3R1ZHlpbmcgaXQuDQoNClBhdmVsDQoNCk9uIDgvMjQvMTgg
Mzo0NCBBTSwgSmlyaSBTbGFieSB3cm90ZToNCj4gcGFzaGEudGF0YXNoaW5Ab3JhY2xlLmNvbSAt
PiBwYXZlbC50YXRhc2hpbkBtaWNyb3NvZnQuY29tDQo+IA0KPiBkdWUgdG8NCj4gIDU1MCA1LjEu
MSBVbmtub3duIHJlY2lwaWVudCBhZGRyZXNzLg0KPiANCj4gDQo+IE9uIDA4LzI0LzIwMTgsIDA5
OjMyIEFNLCBKaXJpIFNsYWJ5IHdyb3RlOg0KPj4gT24gMDYvMTkvMjAxOCwgMDk6NTYgUE0sIFBh
dmVsIFRhdGFzaGluIHdyb3RlOg0KPj4+IE9uIFR1ZSwgSnVuIDE5LCAyMDE4IGF0IDk6NTAgQU0g
UGF2ZWwgVGF0YXNoaW4NCj4+PiA8cGFzaGEudGF0YXNoaW5Ab3JhY2xlLmNvbT4gd3JvdGU6DQo+
Pj4+DQo+Pj4+IE9uIFNhdCwgSnVuIDE2LCAyMDE4IGF0IDQ6MDQgQU0gSmlyaSBTbGFieSA8anNs
YWJ5QHN1c2UuY3o+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+IE9uIDExLzIxLzIwMTcsIDA4OjI0IEFN
LCBNaWNoYWwgSG9ja28gd3JvdGU6DQo+Pj4+Pj4gT24gVGh1IDE2LTExLTE3IDIwOjQ2OjAxLCBQ
YXZlbCBUYXRhc2hpbiB3cm90ZToNCj4+Pj4+Pj4gVGhlcmUgaXMgbm8gbmVlZCB0byBoYXZlIEFS
Q0hfU1VQUE9SVFNfREVGRVJSRURfU1RSVUNUX1BBR0VfSU5JVCwNCj4+Pj4+Pj4gYXMgYWxsIHRo
ZSBwYWdlIGluaXRpYWxpemF0aW9uIGNvZGUgaXMgaW4gY29tbW9uIGNvZGUuDQo+Pj4+Pj4+DQo+
Pj4+Pj4+IEFsc28sIHRoZXJlIGlzIG5vIG5lZWQgdG8gZGVwZW5kIG9uIE1FTU9SWV9IT1RQTFVH
LCBhcyBpbml0aWFsaXphdGlvbiBjb2RlDQo+Pj4+Pj4+IGRvZXMgbm90IHJlYWxseSB1c2UgaG90
cGx1ZyBtZW1vcnkgZnVuY3Rpb25hbGl0eS4gU28sIHdlIGNhbiByZW1vdmUgdGhpcw0KPj4+Pj4+
PiByZXF1aXJlbWVudCBhcyB3ZWxsLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGlzIHBhdGNoIGFsbG93
cyB0byB1c2UgZGVmZXJyZWQgc3RydWN0IHBhZ2UgaW5pdGlhbGl6YXRpb24gb24gYWxsDQo+Pj4+
Pj4+IHBsYXRmb3JtcyB3aXRoIG1lbWJsb2NrIGFsbG9jYXRvci4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g
VGVzdGVkIG9uIHg4NiwgYXJtNjQsIGFuZCBzcGFyYy4gQWxzbywgdmVyaWZpZWQgdGhhdCBjb2Rl
IGNvbXBpbGVzIG9uDQo+Pj4+Pj4+IFBQQyB3aXRoIENPTkZJR19NRU1PUllfSE9UUExVRyBkaXNh
YmxlZC4NCj4+Pj4+Pg0KPj4+Pj4+IFRoZXJlIGlzIHNsaWdodCByaXNrIHRoYXQgd2Ugd2lsbCBl
bmNvdW50ZXIgY29ybmVyIGNhc2VzIG9uIHNvbWUNCj4+Pj4+PiBhcmNoaXRlY3R1cmVzIHdpdGgg
d2VpcmQgbWVtb3J5IGxheW91dC90b3BvbG9neQ0KPj4+Pj4NCj4+Pj4+IFdoaWNoIHg4Nl8zMi1w
YWUgc2VlbXMgdG8gYmUuIE1hbnkgYmFkIHBhZ2Ugc3RhdGUgZXJyb3JzIGFyZSBlbWl0dGVkDQo+
Pj4+PiBkdXJpbmcgYm9vdCB3aGVuIHRoaXMgcGF0Y2ggaXMgYXBwbGllZDoNCj4+Pj4NCj4+Pj4g
SGkgSmlyaSwNCj4+Pj4NCj4+Pj4gVGhhbmsgeW91IGZvciByZXBvcnRpbmcgdGhpcyBidWcuDQo+
Pj4+DQo+Pj4+IEJlY2F1c2UgMzItYml0IHN5c3RlbXMgYXJlIGxpbWl0ZWQgaW4gdGhlIG1heGlt
dW0gYW1vdW50IG9mIHBoeXNpY2FsDQo+Pj4+IG1lbW9yeSwgdGhleSBkb24ndCBuZWVkIGRlZmVy
cmVkIHN0cnVjdCBwYWdlcy4gU28sIHdlIGNhbiBhZGQgZGVwZW5kcw0KPj4+PiBvbiA2NEJJVCB0
byBERUZFUlJFRF9TVFJVQ1RfUEFHRV9JTklUIGluIG1tL0tjb25maWcuDQo+Pj4+DQo+Pj4+IEhv
d2V2ZXIsIGJlZm9yZSB3ZSBkbyB0aGlzLCBJIHdhbnQgdG8gdHJ5IHJlcHJvZHVjaW5nIHRoaXMg
cHJvYmxlbSBhbmQNCj4+Pj4gcm9vdCBjYXVzZSBpdCwgYXMgaXQgbWlnaHQgZXhwb3NlIGEgZ2Vu
ZXJhbCBwcm9ibGVtIHRoYXQgaXMgbm90IDMyLWJpdA0KPj4+PiBzcGVjaWZpYy4NCj4+Pg0KPj4+
IEhpIEppcmksDQo+Pj4NCj4+PiBDb3VsZCB5b3UgcGxlYXNlIGF0dGFjaCB5b3VyIGNvbmZpZyBh
bmQgZnVsbCBxZW11IGFyZ3VtZW50cyB0aGF0IHlvdQ0KPj4+IHVzZWQgdG8gcmVwcm9kdWNlIHRo
aXMgYnVnLg0KPj4NCj4+IEhpLA0KPj4NCj4+IEkgc2VlbSBJIG5ldmVyIHJlcGxpZWQuIEF0dGFj
aGluZyAuY29uZmlnIGFuZCB0aGUgcWVtdSBjbWRsaW5lOg0KPj4gJCBxZW11LWt2bSAtbSAyMDAw
IC1oZGEgL2Rldi9udWxsIC1rZXJuZWwgYnpJbWFnZQ0KPj4NCj4+ICItbSAyMDAwIiBpcyBpbXBv
cnRhbnQgdG8gcmVwcm9kdWNlLg0KPj4NCj4+IElmIEkgZGlzYWJsZSBDT05GSUdfREVGRVJSRURf
U1RSVUNUX1BBR0VfSU5JVCAod2hpY2ggdGhlIHBhdGNoIGFsbG93ZWQNCj4+IHRvIGVuYWJsZSks
IHRoZSBlcnJvciBnb2VzIGF3YXksIG9mIGNvdXJzZS4NCj4+DQo+PiB0aGFua3MsDQo+Pg0KPiAN
Cj4g
^ permalink raw reply
* Re: [PATCH v1] mm: relax deferred struct page requirements
From: Pasha Tatashin @ 2018-08-30 15:45 UTC (permalink / raw)
To: Jiri Slaby
Cc: mhocko@kernel.org, Steven Sistare, Daniel Jordan,
benh@kernel.crashing.org, paulus@samba.org, Andrew Morton,
kirill.shutemov@linux.intel.com, Reza Arbab,
schwidefsky@de.ibm.com, Heiko Carstens, x86@kernel.org, LKML,
tglx@linutronix.de, linuxppc-dev@lists.ozlabs.org,
Linux Memory Management List, linux-s390@vger.kernel.org,
mgorman@techsingularity.net
In-Reply-To: <7aee9274-9e8e-4a40-a9e5-3c9ef28511b7@microsoft.com>
SGkgSmlyaSwNCg0KSSBiZWxpZXZlIHRoaXMgYnVnIGlzIGZpeGVkIHdpdGggdGhpcyBjaGFuZ2U6
DQoNCmQzOWY4ZmI0Yjc3NzZkY2IwOWVjM2JmN2EzMjE1NDcwODMwNzhlZTMNCm1tOiBtYWtlIERF
RkVSUkVEX1NUUlVDVF9QQUdFX0lOSVQgZXhwbGljaXRseSBkZXBlbmQgb24gU1BBUlNFTUVNDQoN
CkkgYW0gbm90IGFibGUgdG8gcmVwcm9kdWNlIHRoaXMgcHJvYmxlbSBvbiB4ODYtMzIuDQoNClBh
dmVsDQoNCk9uIDgvMzAvMTggMTA6MzUgQU0sIFBhdmVsIFRhdGFzaGluIHdyb3RlOg0KPiBUaGFu
ayB5b3UgSmlyaSwgSSBhbSBzdHVkeWluZyBpdC4NCj4gDQo+IFBhdmVsDQo+IA0KPiBPbiA4LzI0
LzE4IDM6NDQgQU0sIEppcmkgU2xhYnkgd3JvdGU6DQo+PiBwYXNoYS50YXRhc2hpbkBvcmFjbGUu
Y29tIC0+IHBhdmVsLnRhdGFzaGluQG1pY3Jvc29mdC5jb20NCj4+DQo+PiBkdWUgdG8NCj4+ICA1
NTAgNS4xLjEgVW5rbm93biByZWNpcGllbnQgYWRkcmVzcy4NCj4+DQo+Pg0KPj4gT24gMDgvMjQv
MjAxOCwgMDk6MzIgQU0sIEppcmkgU2xhYnkgd3JvdGU6DQo+Pj4gT24gMDYvMTkvMjAxOCwgMDk6
NTYgUE0sIFBhdmVsIFRhdGFzaGluIHdyb3RlOg0KPj4+PiBPbiBUdWUsIEp1biAxOSwgMjAxOCBh
dCA5OjUwIEFNIFBhdmVsIFRhdGFzaGluDQo+Pj4+IDxwYXNoYS50YXRhc2hpbkBvcmFjbGUuY29t
PiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBPbiBTYXQsIEp1biAxNiwgMjAxOCBhdCA0OjA0IEFNIEpp
cmkgU2xhYnkgPGpzbGFieUBzdXNlLmN6PiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IE9uIDExLzIx
LzIwMTcsIDA4OjI0IEFNLCBNaWNoYWwgSG9ja28gd3JvdGU6DQo+Pj4+Pj4+IE9uIFRodSAxNi0x
MS0xNyAyMDo0NjowMSwgUGF2ZWwgVGF0YXNoaW4gd3JvdGU6DQo+Pj4+Pj4+PiBUaGVyZSBpcyBu
byBuZWVkIHRvIGhhdmUgQVJDSF9TVVBQT1JUU19ERUZFUlJFRF9TVFJVQ1RfUEFHRV9JTklULA0K
Pj4+Pj4+Pj4gYXMgYWxsIHRoZSBwYWdlIGluaXRpYWxpemF0aW9uIGNvZGUgaXMgaW4gY29tbW9u
IGNvZGUuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQWxzbywgdGhlcmUgaXMgbm8gbmVlZCB0byBkZXBl
bmQgb24gTUVNT1JZX0hPVFBMVUcsIGFzIGluaXRpYWxpemF0aW9uIGNvZGUNCj4+Pj4+Pj4+IGRv
ZXMgbm90IHJlYWxseSB1c2UgaG90cGx1ZyBtZW1vcnkgZnVuY3Rpb25hbGl0eS4gU28sIHdlIGNh
biByZW1vdmUgdGhpcw0KPj4+Pj4+Pj4gcmVxdWlyZW1lbnQgYXMgd2VsbC4NCj4+Pj4+Pj4+DQo+
Pj4+Pj4+PiBUaGlzIHBhdGNoIGFsbG93cyB0byB1c2UgZGVmZXJyZWQgc3RydWN0IHBhZ2UgaW5p
dGlhbGl6YXRpb24gb24gYWxsDQo+Pj4+Pj4+PiBwbGF0Zm9ybXMgd2l0aCBtZW1ibG9jayBhbGxv
Y2F0b3IuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGVzdGVkIG9uIHg4NiwgYXJtNjQsIGFuZCBzcGFy
Yy4gQWxzbywgdmVyaWZpZWQgdGhhdCBjb2RlIGNvbXBpbGVzIG9uDQo+Pj4+Pj4+PiBQUEMgd2l0
aCBDT05GSUdfTUVNT1JZX0hPVFBMVUcgZGlzYWJsZWQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZXJl
IGlzIHNsaWdodCByaXNrIHRoYXQgd2Ugd2lsbCBlbmNvdW50ZXIgY29ybmVyIGNhc2VzIG9uIHNv
bWUNCj4+Pj4+Pj4gYXJjaGl0ZWN0dXJlcyB3aXRoIHdlaXJkIG1lbW9yeSBsYXlvdXQvdG9wb2xv
Z3kNCj4+Pj4+Pg0KPj4+Pj4+IFdoaWNoIHg4Nl8zMi1wYWUgc2VlbXMgdG8gYmUuIE1hbnkgYmFk
IHBhZ2Ugc3RhdGUgZXJyb3JzIGFyZSBlbWl0dGVkDQo+Pj4+Pj4gZHVyaW5nIGJvb3Qgd2hlbiB0
aGlzIHBhdGNoIGlzIGFwcGxpZWQ6DQo+Pj4+Pg0KPj4+Pj4gSGkgSmlyaSwNCj4+Pj4+DQo+Pj4+
PiBUaGFuayB5b3UgZm9yIHJlcG9ydGluZyB0aGlzIGJ1Zy4NCj4+Pj4+DQo+Pj4+PiBCZWNhdXNl
IDMyLWJpdCBzeXN0ZW1zIGFyZSBsaW1pdGVkIGluIHRoZSBtYXhpbXVtIGFtb3VudCBvZiBwaHlz
aWNhbA0KPj4+Pj4gbWVtb3J5LCB0aGV5IGRvbid0IG5lZWQgZGVmZXJyZWQgc3RydWN0IHBhZ2Vz
LiBTbywgd2UgY2FuIGFkZCBkZXBlbmRzDQo+Pj4+PiBvbiA2NEJJVCB0byBERUZFUlJFRF9TVFJV
Q1RfUEFHRV9JTklUIGluIG1tL0tjb25maWcuDQo+Pj4+Pg0KPj4+Pj4gSG93ZXZlciwgYmVmb3Jl
IHdlIGRvIHRoaXMsIEkgd2FudCB0byB0cnkgcmVwcm9kdWNpbmcgdGhpcyBwcm9ibGVtIGFuZA0K
Pj4+Pj4gcm9vdCBjYXVzZSBpdCwgYXMgaXQgbWlnaHQgZXhwb3NlIGEgZ2VuZXJhbCBwcm9ibGVt
IHRoYXQgaXMgbm90IDMyLWJpdA0KPj4+Pj4gc3BlY2lmaWMuDQo+Pj4+DQo+Pj4+IEhpIEppcmks
DQo+Pj4+DQo+Pj4+IENvdWxkIHlvdSBwbGVhc2UgYXR0YWNoIHlvdXIgY29uZmlnIGFuZCBmdWxs
IHFlbXUgYXJndW1lbnRzIHRoYXQgeW91DQo+Pj4+IHVzZWQgdG8gcmVwcm9kdWNlIHRoaXMgYnVn
Lg0KPj4+DQo+Pj4gSGksDQo+Pj4NCj4+PiBJIHNlZW0gSSBuZXZlciByZXBsaWVkLiBBdHRhY2hp
bmcgLmNvbmZpZyBhbmQgdGhlIHFlbXUgY21kbGluZToNCj4+PiAkIHFlbXUta3ZtIC1tIDIwMDAg
LWhkYSAvZGV2L251bGwgLWtlcm5lbCBiekltYWdlDQo+Pj4NCj4+PiAiLW0gMjAwMCIgaXMgaW1w
b3J0YW50IHRvIHJlcHJvZHVjZS4NCj4+Pg0KPj4+IElmIEkgZGlzYWJsZSBDT05GSUdfREVGRVJS
RURfU1RSVUNUX1BBR0VfSU5JVCAod2hpY2ggdGhlIHBhdGNoIGFsbG93ZWQNCj4+PiB0byBlbmFi
bGUpLCB0aGUgZXJyb3IgZ29lcyBhd2F5LCBvZiBjb3Vyc2UuDQo+Pj4NCj4+PiB0aGFua3MsDQo+
Pj4NCj4+DQo+Pg==
^ permalink raw reply
* Re: [PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock
From: Pasha Tatashin @ 2018-08-30 15:54 UTC (permalink / raw)
To: David Hildenbrand, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
xen-devel@lists.xenproject.org, devel@linuxdriverproject.org,
Andrew Morton, Balbir Singh, Benjamin Herrenschmidt,
Boris Ostrovsky, Dan Williams, Greg Kroah-Hartman, Haiyang Zhang,
Heiko Carstens, John Allen, Jonathan Corbet, Joonsoo Kim,
Juergen Gross, Kate Stewart, KY Srinivasan, Len Brown,
Martin Schwidefsky, Mathieu Malaterre, Michael Ellerman,
Michael Neuling, Michal Hocko, Nathan Fontenot, Oscar Salvador,
Paul Mackerras, Philippe Ombredanne, Rafael J. Wysocki,
Rashmica Gupta, Stephen Hemminger, Thomas Gleixner,
Vlastimil Babka, YASUAKI ISHIMATSU
In-Reply-To: <37ea507e-b16d-ae8d-4da8-128b621869f2@redhat.com>
DQoNCk9uIDgvMzAvMTggODozMSBBTSwgRGF2aWQgSGlsZGVuYnJhbmQgd3JvdGU6DQo+IE9uIDIx
LjA4LjIwMTggMTI6NDQsIERhdmlkIEhpbGRlbmJyYW5kIHdyb3RlOg0KPj4gVGhpcyBpcyB0aGUg
c2FtZSBhcHByb2FjaCBhcyBpbiB0aGUgZmlyc3QgUkZDLCBidXQgdGhpcyB0aW1lIHdpdGhvdXQN
Cj4+IGV4cG9ydGluZyBkZXZpY2VfaG90cGx1Z19sb2NrIChyZXF1ZXN0ZWQgYnkgR3JlZykgYW5k
IHdpdGggc29tZSBtb3JlDQo+PiBkZXRhaWxzIGFuZCBkb2N1bWVudGF0aW9uIHJlZ2FyZGluZyBs
b2NraW5nLiBUZXN0ZWQgb25seSBvbiB4ODYgc28gZmFyLg0KPj4NCj4gDQo+IEknbGwgYmUgb24g
dmFjYXRpb24gZm9yIHR3byB3ZWVrcyBzdGFydGluZyBvbiBTYXR1cmRheS4gSWYgdGhlcmUgYXJl
IG5vDQo+IGNvbW1lbnRzIEknbGwgc2VuZCB0aGlzIGFzICFSRkMgb25jZSBJIHJldHVybi4NCj4N
CkkgYW0gc3R1ZHlpbmcgdGhpcyBzZXJpZXMsIHdpbGwgc2VuZCBteSBjb21tZW50cyBsYXRlciB0
b2RheS4NCg0KUGF2ZWw=
^ permalink raw reply
* Re: [PATCH] soc: fsl/qe: Use of_get_child_by_name helper
From: Li Yang @ 2018-08-30 17:04 UTC (permalink / raw)
To: Zhao Qiang
Cc: Rob Herring, lkml, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <VI1PR04MB32475E7E36BA8467FC07B01D91080@VI1PR04MB3247.eurprd04.prod.outlook.com>
On Wed, Aug 29, 2018 at 9:49 PM Qiang Zhao <qiang.zhao@nxp.com> wrote:
>
> From: Rob Herring <robh@kernel.org>
> date: 2018/8/30 4:04
>
> > To: Qiang Zhao <qiang.zhao@nxp.com>
> > Cc: linux-kernel@vger.kernel.org; Leo Li <leoyang.li@nxp.com>;
> > linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org
> > Subject: [PATCH] soc: fsl/qe: Use of_get_child_by_name helper
> >
> > Use the of_get_child_by_name() helper instead of open coding searching for the
> > 'firmware' child node. This removes directly accessing the name pointer as well.
> >
> > Cc: Qiang Zhao <qiang.zhao@nxp.com>
> > Cc: Li Yang <leoyang.li@nxp.com>
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: linux-arm-kernel@lists.infradead.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
Merged for next. Thanks.
Regards,
Leo
^ permalink raw reply
* Re: [PATCH] fsl: remove redundant pointer 'priv'
From: Li Yang @ 2018-08-30 17:23 UTC (permalink / raw)
To: colin.king
Cc: Roy Pledge, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
kernel-janitors, lkml
In-Reply-To: <20180829092746.30674-1-colin.king@canonical.com>
On Wed, Aug 29, 2018 at 4:29 AM Colin King <colin.king@canonical.com> wrote:
>
> From: Colin Ian King <colin.king@canonical.com>
>
> Pointer 'priv' is being assigned but is never used hence it is
> redundant and can be removed.
>
> Cleans up clang warning:
> variable 'priv' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Merged for next after updated the title prefix.
Thanks!
> ---
> drivers/soc/fsl/dpio/dpio-driver.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
> index b60b77bfaffa..e58fcc9096e8 100644
> --- a/drivers/soc/fsl/dpio/dpio-driver.c
> +++ b/drivers/soc/fsl/dpio/dpio-driver.c
> @@ -50,13 +50,10 @@ static void unregister_dpio_irq_handlers(struct fsl_mc_device *dpio_dev)
>
> static int register_dpio_irq_handlers(struct fsl_mc_device *dpio_dev, int cpu)
> {
> - struct dpio_priv *priv;
> int error;
> struct fsl_mc_device_irq *irq;
> cpumask_t mask;
>
> - priv = dev_get_drvdata(&dpio_dev->dev);
> -
> irq = dpio_dev->irqs[0];
> error = devm_request_irq(&dpio_dev->dev,
> irq->msi_desc->irq,
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a
From: Scott Wood @ 2018-08-30 17:39 UTC (permalink / raw)
To: Vabhav Sharma, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, mturquette@baylibre.com,
sboyd@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel-owner@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, gregkh@linuxfoundation.org, arnd@arndb.de,
kstewart@linuxfoundation.org, yamada.masahiro@socionext.com
Cc: Yogesh Narayan Gaur, Andy Tang, Udit Kumar, linux@armlinux.org.uk,
Varun Sethi
In-Reply-To: <VI1PR04MB4800E8B1E8541FCA9221A1CFF3080@VI1PR04MB4800.eurprd04.prod.outlook.com>
On Thu, 2018-08-30 at 07:36 +0000, Vabhav Sharma wrote:
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org <linux-kernel-
> > owner@vger.kernel.org> On Behalf Of Scott Wood
> > Sent: Wednesday, August 29, 2018 5:49 AM
> > To: Vabhav Sharma <vabhav.sharma@nxp.com>; linux-
> > kernel@vger.kernel.org; devicetree@vger.kernel.org; robh+dt@kernel.org;
> > mark.rutland@arm.com; linuxppc-dev@lists.ozlabs.org; linux-arm-
> > kernel@lists.infradead.org; mturquette@baylibre.com; sboyd@kernel.org;
> > rjw@rjwysocki.net; viresh.kumar@linaro.org; linux-clk@vger.kernel.org;
> > linux-pm@vger.kernel.org; linux-kernel-owner@vger.kernel.org;
> > catalin.marinas@arm.com; will.deacon@arm.com;
> > gregkh@linuxfoundation.org; arnd@arndb.de;
> > kstewart@linuxfoundation.org; yamada.masahiro@socionext.com
> > Cc: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Andy Tang
> > <andy.tang@nxp.com>; Udit Kumar <udit.kumar@nxp.com>;
> > linux@armlinux.org.uk; Varun Sethi <V.Sethi@nxp.com>
> > Subject: Re: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for
> > lx2160a
> >
> > On Mon, 2018-08-20 at 12:17 +0530, Vabhav Sharma wrote:
> > > From: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> > >
> > > Add clockgen support for lx2160a.
> > > Added entry for compat 'fsl,lx2160a-clockgen'.
> > > As LX2160A is 16 core, so modified value for NUM_CMUX
> > >
> > > Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
> > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> > > Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> > > ---
> > > drivers/clk/clk-qoriq.c | 14 +++++++++++++-
> > > drivers/cpufreq/qoriq-cpufreq.c | 1 +
> > > 2 files changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c index
> > > 3a1812f..fc6e308 100644
> > > --- a/drivers/clk/clk-qoriq.c
> > > +++ b/drivers/clk/clk-qoriq.c
> > > @@ -60,7 +60,7 @@ struct clockgen_muxinfo { };
> > >
> > > #define NUM_HWACCEL 5
> > > -#define NUM_CMUX 8
> > > +#define NUM_CMUX 16
> > >
> > > struct clockgen;
> > >
> > > @@ -570,6 +570,17 @@ static const struct clockgen_chipinfo chipinfo[] =
> > > {
> > > .flags = CG_VER3 | CG_LITTLE_ENDIAN,
> > > },
> > > {
> > > + .compat = "fsl,lx2160a-clockgen",
> > > + .cmux_groups = {
> > > + &clockgen2_cmux_cga12, &clockgen2_cmux_cgb
> > > + },
> > > + .cmux_to_group = {
> > > + 0, 0, 0, 0, 1, 1, 1, 1, -1
> > > + },
> > > + .pll_mask = 0x37,
> > > + .flags = CG_VER3 | CG_LITTLE_ENDIAN,
> > > + },
> >
> > Why are you increasing NUM_CMUX beyond 8 for a chip that only has 8
> > entries in cmux_to_group?
>
> Configuration is 16 cores,8 cluster with 2 cores in each cluster
So? This is about cmuxes, not cores. You're increasing the array without
ever using the new size.
-Scott
^ permalink raw reply
* Re: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a
From: Scott Wood @ 2018-08-30 17:42 UTC (permalink / raw)
To: Vabhav Sharma, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, mturquette@baylibre.com,
sboyd@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel-owner@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, gregkh@linuxfoundation.org, arnd@arndb.de,
kstewart@linuxfoundation.org, yamada.masahiro@socionext.com
Cc: Yogesh Narayan Gaur, Andy Tang, Udit Kumar, linux@armlinux.org.uk,
Varun Sethi
In-Reply-To: <d2cfd49eb33a3ce74f0e78f2b53d3954d2cb3e76.camel@buserror.net>
On Thu, 2018-08-30 at 12:39 -0500, Scott Wood wrote:
> On Thu, 2018-08-30 at 07:36 +0000, Vabhav Sharma wrote:
> > > -----Original Message-----
> > > From: linux-kernel-owner@vger.kernel.org <linux-kernel-
> > > owner@vger.kernel.org> On Behalf Of Scott Wood
> > > Sent: Wednesday, August 29, 2018 5:49 AM
> > > To: Vabhav Sharma <vabhav.sharma@nxp.com>; linux-
> > > kernel@vger.kernel.org; devicetree@vger.kernel.org; robh+dt@kernel.org;
> > > mark.rutland@arm.com; linuxppc-dev@lists.ozlabs.org; linux-arm-
> > > kernel@lists.infradead.org; mturquette@baylibre.com; sboyd@kernel.org;
> > > rjw@rjwysocki.net; viresh.kumar@linaro.org; linux-clk@vger.kernel.org;
> > > linux-pm@vger.kernel.org; linux-kernel-owner@vger.kernel.org;
> > > catalin.marinas@arm.com; will.deacon@arm.com;
> > > gregkh@linuxfoundation.org; arnd@arndb.de;
> > > kstewart@linuxfoundation.org; yamada.masahiro@socionext.com
> > > Cc: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Andy Tang
> > > <andy.tang@nxp.com>; Udit Kumar <udit.kumar@nxp.com>;
> > > linux@armlinux.org.uk; Varun Sethi <V.Sethi@nxp.com>
> > > Subject: Re: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for
> > > lx2160a
> > >
> > > On Mon, 2018-08-20 at 12:17 +0530, Vabhav Sharma wrote:
> > > > From: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> > > >
> > > > Add clockgen support for lx2160a.
> > > > Added entry for compat 'fsl,lx2160a-clockgen'.
> > > > As LX2160A is 16 core, so modified value for NUM_CMUX
> > > >
> > > > Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
> > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> > > > Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> > > > ---
> > > > drivers/clk/clk-qoriq.c | 14 +++++++++++++-
> > > > drivers/cpufreq/qoriq-cpufreq.c | 1 +
> > > > 2 files changed, 14 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c index
> > > > 3a1812f..fc6e308 100644
> > > > --- a/drivers/clk/clk-qoriq.c
> > > > +++ b/drivers/clk/clk-qoriq.c
> > > > @@ -60,7 +60,7 @@ struct clockgen_muxinfo { };
> > > >
> > > > #define NUM_HWACCEL 5
> > > > -#define NUM_CMUX 8
> > > > +#define NUM_CMUX 16
> > > >
> > > > struct clockgen;
> > > >
> > > > @@ -570,6 +570,17 @@ static const struct clockgen_chipinfo chipinfo[]
> > > > =
> > > > {
> > > > .flags = CG_VER3 | CG_LITTLE_ENDIAN,
> > > > },
> > > > {
> > > > + .compat = "fsl,lx2160a-clockgen",
> > > > + .cmux_groups = {
> > > > + &clockgen2_cmux_cga12, &clockgen2_cmux_cgb
> > > > + },
> > > > + .cmux_to_group = {
> > > > + 0, 0, 0, 0, 1, 1, 1, 1, -1
> > > > + },
> > > > + .pll_mask = 0x37,
> > > > + .flags = CG_VER3 | CG_LITTLE_ENDIAN,
> > > > + },
> > >
> > > Why are you increasing NUM_CMUX beyond 8 for a chip that only has 8
> > > entries in cmux_to_group?
> >
> > Configuration is 16 cores,8 cluster with 2 cores in each cluster
>
> So? This is about cmuxes, not cores. You're increasing the array without
> ever using the new size.
Oh, and you also broke p4080 which has 8 cmuxes but no -1 terminator, because
the array was of length 8. Probably the array should be changed to NUM_CMUX+1
so every array can be -1 terminated.
-Scott
^ permalink raw reply
* [PATCH AUTOSEL 4.18 095/113] powerpc/platforms/85xx: fix t1042rdb_diu.c build errors & warning
From: Sasha Levin @ 2018-08-30 18:08 UTC (permalink / raw)
To: stable@vger.kernel.org
Cc: Randy Dunlap, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Scott Wood, Kumar Gala,
linuxppc-dev@lists.ozlabs.org, Sasha Levin
In-Reply-To: <20180830180714.36167-1-alexander.levin@microsoft.com>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit f5daf77a55ef0e695cc90c440ed6503073ac5e07 ]
Fix build errors and warnings in t1042rdb_diu.c by adding header files
and MODULE_LICENSE().
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: data definiti=
on has no type or storage class
early_initcall(t1042rdb_diu_init);
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: error: type defaults t=
o 'int' in declaration of 'early_initcall' [-Werror=3Dimplicit-int]
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: parameter nam=
es (without types) in function declaration
and
WARNING: modpost: missing MODULE_LICENSE() in arch/powerpc/platforms/85xx/t=
1042rdb_diu.o
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Scott Wood <oss@buserror.net>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
arch/powerpc/platforms/85xx/t1042rdb_diu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/t1042rdb_diu.c b/arch/powerpc/plat=
forms/85xx/t1042rdb_diu.c
index 58fa3d319f1c..dac36ba82fea 100644
--- a/arch/powerpc/platforms/85xx/t1042rdb_diu.c
+++ b/arch/powerpc/platforms/85xx/t1042rdb_diu.c
@@ -9,8 +9,10 @@
* option) any later version.
*/
=20
+#include <linux/init.h>
#include <linux/io.h>
#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_address.h>
=20
@@ -150,3 +152,5 @@ static int __init t1042rdb_diu_init(void)
}
=20
early_initcall(t1042rdb_diu_init);
+
+MODULE_LICENSE("GPL");
--=20
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 57/67] powerpc/platforms/85xx: fix t1042rdb_diu.c build errors & warning
From: Sasha Levin @ 2018-08-30 18:11 UTC (permalink / raw)
To: stable@vger.kernel.org
Cc: Randy Dunlap, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Scott Wood, Kumar Gala,
linuxppc-dev@lists.ozlabs.org, Sasha Levin
In-Reply-To: <20180830180918.36327-1-alexander.levin@microsoft.com>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit f5daf77a55ef0e695cc90c440ed6503073ac5e07 ]
Fix build errors and warnings in t1042rdb_diu.c by adding header files
and MODULE_LICENSE().
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: data definiti=
on has no type or storage class
early_initcall(t1042rdb_diu_init);
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: error: type defaults t=
o 'int' in declaration of 'early_initcall' [-Werror=3Dimplicit-int]
../arch/powerpc/platforms/85xx/t1042rdb_diu.c:152:1: warning: parameter nam=
es (without types) in function declaration
and
WARNING: modpost: missing MODULE_LICENSE() in arch/powerpc/platforms/85xx/t=
1042rdb_diu.o
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Scott Wood <oss@buserror.net>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
arch/powerpc/platforms/85xx/t1042rdb_diu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/t1042rdb_diu.c b/arch/powerpc/plat=
forms/85xx/t1042rdb_diu.c
index 58fa3d319f1c..dac36ba82fea 100644
--- a/arch/powerpc/platforms/85xx/t1042rdb_diu.c
+++ b/arch/powerpc/platforms/85xx/t1042rdb_diu.c
@@ -9,8 +9,10 @@
* option) any later version.
*/
=20
+#include <linux/init.h>
#include <linux/io.h>
#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_address.h>
=20
@@ -150,3 +152,5 @@ static int __init t1042rdb_diu_init(void)
}
=20
early_initcall(t1042rdb_diu_init);
+
+MODULE_LICENSE("GPL");
--=20
2.17.1
^ permalink raw reply related
* Re: [PATCH RFCv2 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock
From: Pasha Tatashin @ 2018-08-30 19:35 UTC (permalink / raw)
To: David Hildenbrand, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
xen-devel@lists.xenproject.org, devel@linuxdriverproject.org,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Rafael J. Wysocki, Len Brown, Rashmica Gupta, Michael Neuling,
Balbir Singh, Nathan Fontenot, John Allen, Andrew Morton,
Michal Hocko, Dan Williams, Joonsoo Kim, Vlastimil Babka,
Greg Kroah-Hartman, Oscar Salvador, YASUAKI ISHIMATSU,
Mathieu Malaterre
In-Reply-To: <20180821104418.12710-2-david@redhat.com>
PiArDQo+ICt2b2lkIF9fcmVmIHJlbW92ZV9tZW1vcnkoaW50IG5pZCwgdTY0IHN0YXJ0LCB1NjQg
c2l6ZSkNCg0KUmVtb3ZlIF9fcmVmLCBvdGhlcndpc2UgbG9va3MgZ29vZDoNCg0KUmV2aWV3ZWQt
Ynk6IFBhdmVsIFRhdGFzaGluIDxwYXZlbC50YXRhc2hpbkBtaWNyb3NvZnQuY29tPg0KDQo+ICt7
DQo+ICsJbG9ja19kZXZpY2VfaG90cGx1ZygpOw0KPiArCV9fcmVtb3ZlX21lbW9yeShuaWQsIHN0
YXJ0LCBzaXplKTsNCj4gKwl1bmxvY2tfZGV2aWNlX2hvdHBsdWcoKTsNCj4gK30NCj4gIEVYUE9S
VF9TWU1CT0xfR1BMKHJlbW92ZV9tZW1vcnkpOw0KPiAgI2VuZGlmIC8qIENPTkZJR19NRU1PUllf
SE9UUkVNT1ZFICovDQo+IA==
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox