Re: [PATCH kernel 3/4] KVM: PPC: Validate TCEs against preregistered memory page sizes
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
Reviewed-by: David Gibson
> ---
> 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),
> + , NULL))
> + return H_TOO_HARD;
> +
> + list_for_each_entry_rcu(stit, >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, ))
> + 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
Re: [PATCH kernel 4/4] KVM: PPC: Propagate errors to the guest when failed instead of ignoring
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
Reviewed-by: David Gibson
> ---
> 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
signature.asc
Description: PGP signature
Re: [PATCH kernel 2/4] KVM: PPC: Inform the userspace about TCE update failures
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
Reviewed-by: David Gibson
> ---
> 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, , )))
> - 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, )))
> - 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, , );
> 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,
> )))
> - 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, , );
> 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
signature.asc
Description: PGP signature
Re: [PATCH kernel 1/4] KVM: PPC: Validate all tces before updating tables
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
Reviewed-by: David Gibson
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
signature.asc
Description: PGP signature
Re: Not able to boot cuImage for the target board with MPC8270 processor
> 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
[PATCH kernel 3/4] KVM: PPC: Validate TCEs against preregistered memory page sizes
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
---
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),
+ , NULL))
+ return H_TOO_HARD;
+
+ list_for_each_entry_rcu(stit, >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, ))
+ 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
[PATCH kernel 2/4] KVM: PPC: Inform the userspace about TCE update failures
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
---
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, , )))
- 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, )))
- 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, , );
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,
)))
- 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, , );
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
[PATCH kernel 1/4] KVM: PPC: Validate all tces before updating tables
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
---
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
[PATCH kernel 0/4] KVM: PPC: Some error handling rework
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
[PATCH kernel 4/4] KVM: PPC: Propagate errors to the guest when failed instead of ignoring
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
---
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
RE: [PATCH] soc: fsl/qe: Use of_get_child_by_name helper
From: Rob Herring
date: 2018/8/30 4:04
> To: Qiang Zhao
> Cc: linux-ker...@vger.kernel.org; Leo Li ;
> linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@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
> Cc: Li Yang
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Rob Herring
> ---
> drivers/soc/fsl/qe/qe.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index
> 2ef6fc6487c1..612d9c551be5 100644
> --- a/drivers/soc/fsl/qe/qe.c
> +++ b/drivers/soc/fsl/qe/qe.c
> @@ -588,11 +588,7 @@ struct qe_firmware_info *qe_get_firmware_info(void)
> }
>
> /* Find the 'firmware' child node */
> - for_each_child_of_node(qe, fw) {
> - if (strcmp(fw->name, "firmware") == 0)
> - break;
> - }
> -
> + fw = of_get_child_by_name(qe, "firmware");
> of_node_put(qe);
>
> /* Did we find the 'firmware' node? */
> --
Acked-by: Qiang Zhao
Re: v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
On Wed, Aug 29, 2018 at 7:44 PM Finn Thain wrote:
>
> Hi Frank,
>
> Linux v4.17 and later will no longer boot on a G3 PowerMac. The boot hangs
> very early, before any video driver loads.
>
> Stan and I were able to bisect the regression between v4.16 and v4.17 and
> arrived at commit 0b3ce78e90fc ("of: cache phandle nodes to reduce cost of
> of_find_node_by_phandle()").
>
> I don't see any obvious bug in 0b3ce78e90fc or b9952b5218ad. But if you
> revert these from v4.18 (which is also affected) that certainly resolves
> the issue.
Perhaps a bad assumption on phandle values causing a problem. Can you
provide a dump of all the phandle or linux,phandle values from
/proc/device-tree.
Rob
Re: [PATCH] i2c: Convert to using %pOFn instead of device_node.name
On Wed, Aug 29, 2018 at 7:25 PM Peter Rosin wrote: > > On 2018-08-29 20:42, Rob Herring wrote: > > On Wed, Aug 29, 2018 at 1:03 PM Peter Rosin wrote: > >> > >> On 2018-08-28 03:52, Rob Herring wrote: > >>> In preparation to remove the node name pointer from struct device_node, > >>> convert printf users to use the %pOFn format specifier. > >>> > >>> Cc: Benjamin Herrenschmidt > >>> Cc: Paul Mackerras > >>> Cc: Michael Ellerman > >>> Cc: Peter Rosin > >>> Cc: linux-...@vger.kernel.org > >>> Cc: linuxppc-dev@lists.ozlabs.org > >>> Signed-off-by: Rob Herring > >>> --- > >>> drivers/i2c/busses/i2c-powermac.c | 15 --- > >>> drivers/i2c/muxes/i2c-mux-gpmux.c | 4 ++-- > >>> 2 files changed, 10 insertions(+), 9 deletions(-) > >>> > >>> diff --git a/drivers/i2c/busses/i2c-powermac.c > >>> b/drivers/i2c/busses/i2c-powermac.c > >>> index f2a2067525ef..b706fd136ca5 100644 > >>> --- a/drivers/i2c/busses/i2c-powermac.c > >>> +++ b/drivers/i2c/busses/i2c-powermac.c > >>> @@ -390,7 +390,6 @@ static int i2c_powermac_probe(struct platform_device > >>> *dev) > >>> struct pmac_i2c_bus *bus = dev_get_platdata(>dev); > >>> struct device_node *parent = NULL; > >> > >> Lose the initializer... > > > > That's pretty much unrelated though. > > I disagree. If you remove the need for the initializer, it's very much > related to also remove the initializer. You're right. I'd stared at it a bit and missed that in fact parent is only accessed within the case statement. Rob
v4.17 regression: PowerMac G3 won't boot, was Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
Hi Frank,
Linux v4.17 and later will no longer boot on a G3 PowerMac. The boot hangs
very early, before any video driver loads.
Stan and I were able to bisect the regression between v4.16 and v4.17 and
arrived at commit 0b3ce78e90fc ("of: cache phandle nodes to reduce cost of
of_find_node_by_phandle()").
I don't see any obvious bug in 0b3ce78e90fc or b9952b5218ad. But if you
revert these from v4.18 (which is also affected) that certainly resolves
the issue.
I did see this in the kernel messages:
Duplicate name in PowerPC,750, renamed to "l2-cache#1"
Duplicate name in mac-io, renamed to "ide#1"
Duplicate name in ide#1, renamed to "atapi-disk#1"
Duplicate name in multifunc-device, renamed to "pci1799,1#1"
No idea whether that's relevant; I haven't done any further investigation.
Complete dmesg output is attached. Please let me know if there's any more
information you need to help find the bug.
Thanks.
--
On Sun, 4 Mar 2018, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Create a cache of the nodes that contain a phandle property. Use this
> cache to find the node for a given phandle value instead of scanning
> the devicetree to find the node. If the phandle value is not found
> in the cache, of_find_node_by_phandle() will fall back to the tree
> scan algorithm.
>
> The cache is initialized in of_core_init().
>
> The cache is freed via a late_initcall_sync() if modules are not
> enabled.
>
> If the devicetree is created by the dtc compiler, with all phandle
> property values auto generated, then the size required by the cache
> could be 4 * (1 + number of phandles) bytes. This results in an O(1)
> node lookup cost for a given phandle value. Due to a concern that the
> phandle property values might not be consistent with what is generated
> by the dtc compiler, a mask has been added to the cache lookup algorithm.
> To maintain the O(1) node lookup cost, the size of the cache has been
> increased by rounding the number of entries up to the next power of
> two.
>
> The overhead of finding the devicetree node containing a given phandle
> value has been noted by several people in the recent past, in some cases
> with a patch to add a hashed index of devicetree nodes, based on the
> phandle value of the node. One concern with this approach is the extra
> space added to each node. This patch takes advantage of the phandle
> property values auto generated by the dtc compiler, which begin with
> one and monotonically increase by one, resulting in a range of 1..n
> for n phandle values. This implementation should also provide a good
> reduction of overhead for any range of phandle values that are mostly
> in a monotonic range.
>
> Performance measurements by Chintan Pandya
> of several implementations of patches that are similar to this one
> suggest an expected reduction of boot time by ~400ms for his test
> system. If the cache size was decreased to 64 entries, the boot
> time was reduced by ~340 ms. The measurements were on a 4.9.73 kernel
> for arch/arm64/boot/dts/qcom/sda670-mtp.dts, contains 2371 nodes and
> 814 phandle values.
>
> Reported-by: Chintan Pandya
> Signed-off-by: Frank Rowand
> ---
>
> Changes since v3:
> - of_populate_phandle_cache(): add check for failed memory allocation
>
> Changes since v2:
> - add mask to calculation of phandle cache entry
> - which results in better overhead reduction for devicetrees with
> phandle properties not allocated in the monotonically increasing
> range of 1..n
> - due to mask, number of entries in cache potentially increased to
> next power of two
> - minor fixes as suggested by reviewers
> - no longer using live_tree_max_phandle() so do not move it from
> drivers/of/resolver.c to drivers/of/base.c
>
> Changes since v1:
> - change short description from
> of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
> - rebase on v4.16-rc1
> - reorder new functions in base.c to avoid forward declaration
> - add locking around kfree(phandle_cache) for memory ordering
> - add explicit check for non-null of phandle_cache in
> of_find_node_by_phandle(). There is already a check for !handle,
> which prevents accessing a null phandle_cache, but that dependency
> is not obvious, so this check makes it more apparent.
> - do not free phandle_cache if modules are enabled, so that
> cached phandles will be available when modules are loaded
>
> drivers/of/base.c | 86
> ++---
> drivers/of/of_private.h | 3 ++
> drivers/of/resolver.c | 3 --
> 3 files changed, 85 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index ad28de96e13f..e71d157d7149 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -91,10 +91,72 @@ int __weak of_node_to_nid(struct device_node *np)
> }
> #endif
>
> +static struct device_node **phandle_cache;
> +static u32 phandle_cache_mask;
>
Re: [PATCH 2/3] mm/cow: optimise pte dirty/accessed bits handling in fork
On Wed, 29 Aug 2018 16:15:37 -0700 Linus Torvalds wrote: > On Wed, Aug 29, 2018 at 4:12 PM Nicholas Piggin wrote: > > > > Dirty micro fault seems to be the big one for my Skylake, takes 300 > > nanoseconds per access. Accessed takes about 100. (I think, have to > > go over my benchmark a bit more carefully and re-test). > > Yeah, but they only happen for shared areas after fork, which sounds > like it shouldn't be a big deal in most cases. You might be right there. > > And I'm not entirely objecting to your patch per se, I just would want > to keep the accessed bit changes separate from the dirty bit ones. > > *If* somebody has bisectable issues with it (performance or not), it > will then be clearer what the exact issue is. Yeah that makes a lot of sense. I'll do a bit more testing and send Andrew a respin at least with those split (and a good comment for the dirty bit vs unmap handling that you pointed out). Thanks, Nick
Re: FSL/NXP P5020: USB problems with the latest Git kernels
On Tue, 2018-08-28 at 20:13 +0100, Darren Stevens wrote: > Hello Scott > > On 27/08/2018, Scott Wood wrote: > > On Mon, 2018-08-27 at 20:15 +0200, Christian Zigotzky wrote: > > > Hello, > > > > > > Our users tested the RC1 of kernel 4.19 on their P5020 boards today. > > > Unfortunately the USB bug still exists. With mem values bigger than > > > 4096M, > > > the USB mouse and keyboard doesn't work. With the bootarg mem=4096M, the > > > USB > > > devices work without any problems. Please compile the RC1 and test it on > > > your P5020 board. There is a problem with the memory management since > > > 22/08/18. > > > > I just tested 4.19-rc1 on a T4240 and got a similar problem with MMC. MMC > > and > > USB on these chips both have a 32-bit DMA limitation. I'll look into it. > > I've run a bisect locally on my system and found the following bad commit: > > # first bad commit: [1b1eeca7e4c19fa76d409d4c7b338dba21f2df45] init: allow > initcall tables to be emitted using relative references > > I can't see why this would fail though, and it only seems to affect fsl > machines, and on mine it killed the onboard sata as well. > > Hope this helps. The patch is changing the order of initcalls. swiotlb_setup_bus_notifier() and corenet_gen_publish_devices() are both machine_arch_initcall(), and if the latter happens before the former, then the bus notifier gets missed and swiotlb doesn't get used. -Scott
Re: [PATCH 2/3] mm/cow: optimise pte dirty/accessed bits handling in fork
On Wed, Aug 29, 2018 at 4:12 PM Nicholas Piggin wrote: > > Dirty micro fault seems to be the big one for my Skylake, takes 300 > nanoseconds per access. Accessed takes about 100. (I think, have to > go over my benchmark a bit more carefully and re-test). Yeah, but they only happen for shared areas after fork, which sounds like it shouldn't be a big deal in most cases. And I'm not entirely objecting to your patch per se, I just would want to keep the accessed bit changes separate from the dirty bit ones. *If* somebody has bisectable issues with it (performance or not), it will then be clearer what the exact issue is. Linus
Re: [PATCH 2/3] mm/cow: optimise pte dirty/accessed bits handling in fork
On Wed, 29 Aug 2018 08:42:09 -0700 Linus Torvalds wrote: > On Tue, Aug 28, 2018 at 4:20 AM Nicholas Piggin wrote: > > > > fork clears dirty/accessed bits from new ptes in the child. This logic > > has existed since mapped page reclaim was done by scanning ptes when > > it may have been quite important. Today with physical based pte > > scanning, there is less reason to clear these bits. > > Can you humor me, and make the dirty/accessed bit patches separate? Yeah sure. > There is actually a difference wrt the dirty bit: if we unmap an area > with dirty pages, we have to do the special synchronous flush. > > So a clean page in the virtual mapping is _literally_ cheaper to have. Oh yeah true, that blasted thing. Good point. Dirty micro fault seems to be the big one for my Skylake, takes 300 nanoseconds per access. Accessed takes about 100. (I think, have to go over my benchmark a bit more carefully and re-test). Dirty will happen less often though, particularly as most places we do write to (stack, heap, etc) will be write protected for COW anyway, I think. Worst case might be a big shared shm segment like a database buffer cache, but those kind of forks should happen very very infrequently I would hope. Yes maybe we can do that. I'll split them up and try to get some numbers for them individually. Thanks, Nick
Re: [PATCH] fsl/qe: ucc: copy and paste bug in ucc_get_tdm_sync_shift()
On Wed, Aug 29, 2018 at 4:42 AM Dan Carpenter wrote: > > On Mon, Jun 04, 2018 at 02:06:45PM +0200, Mathieu Malaterre wrote: > > Where did the original go ? > > > > https://patchwork.ozlabs.org/patch/868158/ > > > > > > Btw, we still haven't pushed a patch for this bug. I will combine Zhao Qiang's patch with your description which is better, and push as fix for 4.19. Regards, Leo
Re: [PATCH] hwmon: drop unnecessary OF name NULL checks
On Wed, Aug 29, 2018 at 03:02:21PM -0500, Rob Herring wrote:
> Checking the child node names is pointless as the DT node name can
> never be NULL, so remove it.
>
> Cc: Jean Delvare
> Cc: Guenter Roeck
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: linux-hw...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring
Applied to hwmon-next.
Thanks,
Guenter
> ---
> drivers/hwmon/ibmpowernv.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 4935897f1527..0ccca87f5271 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -458,9 +458,6 @@ static int populate_attr_groups(struct platform_device
> *pdev)
> for_each_child_of_node(opal, np) {
> const char *label;
>
> - if (np->name == NULL)
> - continue;
> -
> type = get_sensor_type(np);
> if (type == MAX_SENSOR_TYPE)
> continue;
> @@ -589,9 +586,6 @@ static int create_device_attrs(struct platform_device
> *pdev)
> const char *label;
> enum sensors type;
>
> - if (np->name == NULL)
> - continue;
> -
> type = get_sensor_type(np);
> if (type == MAX_SENSOR_TYPE)
> continue;
> --
> 2.17.1
>
[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
Cc: Li Yang
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Rob Herring
---
drivers/soc/fsl/qe/qe.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 2ef6fc6487c1..612d9c551be5 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -588,11 +588,7 @@ struct qe_firmware_info *qe_get_firmware_info(void)
}
/* Find the 'firmware' child node */
- for_each_child_of_node(qe, fw) {
- if (strcmp(fw->name, "firmware") == 0)
- break;
- }
-
+ fw = of_get_child_by_name(qe, "firmware");
of_node_put(qe);
/* Did we find the 'firmware' node? */
--
2.17.1
[PATCH] hwmon: drop unnecessary OF name NULL checks
Checking the child node names is pointless as the DT node name can
never be NULL, so remove it.
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linux-hw...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Rob Herring
---
drivers/hwmon/ibmpowernv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 4935897f1527..0ccca87f5271 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -458,9 +458,6 @@ static int populate_attr_groups(struct platform_device
*pdev)
for_each_child_of_node(opal, np) {
const char *label;
- if (np->name == NULL)
- continue;
-
type = get_sensor_type(np);
if (type == MAX_SENSOR_TYPE)
continue;
@@ -589,9 +586,6 @@ static int create_device_attrs(struct platform_device *pdev)
const char *label;
enum sensors type;
- if (np->name == NULL)
- continue;
-
type = get_sensor_type(np);
if (type == MAX_SENSOR_TYPE)
continue;
--
2.17.1
Re: Not able to boot cuImage for the target board with MPC8270 processor
On Wed, 2018-08-29 at 04:14 -0700, sgosavi1 wrote: > Press to STOP AUTOBOOT!:autoboot in 2 seconds > ## Booting image at ffc0 ... >Image Name: Linux-4.15.13 >Created: 2018-08-29 10:45:39 UTC >Image Type: PowerPC Linux Kernel Image (gzip compressed) >Data Size:1166748 Bytes = 1.1 MB >Load Address: 0040 >Entry Point: 004007a4 >Verifying Checksum ... OK >Uncompressing Kernel Image ... OK > > > I also checked the kernel dump at location associated with "_log_buf" symbol > in the System.map file in RAM but did not get any debug info. If you didn't get any output beyond this then it's probably[1] failing in the bootwrapper, not the kernel itself -- so neither _log_buf nor CONFIG_PPC_EARLY_DEBUG would help. > Please can anyone suggest if I am missing something here and how can I get > the debug output on my serial console during bootup. To debug, if you aren't able to use JTAG, add code to the bootwrapper to manually poke at known CPM serial addresses early on, to see how far it's progressing. Are you sure the device tree you're using is correct for your board, including all addresses being where your U-Boot configured them? -Scott [1] Another possibility would be that it's booting, but serial output isn't working.
Re: [PATCH] i2c: Convert to using %pOFn instead of device_node.name
On 2018-08-29 20:42, Rob Herring wrote: > On Wed, Aug 29, 2018 at 1:03 PM Peter Rosin wrote: >> >> On 2018-08-28 03:52, Rob Herring wrote: >>> In preparation to remove the node name pointer from struct device_node, >>> convert printf users to use the %pOFn format specifier. >>> >>> Cc: Benjamin Herrenschmidt >>> Cc: Paul Mackerras >>> Cc: Michael Ellerman >>> Cc: Peter Rosin >>> Cc: linux-...@vger.kernel.org >>> Cc: linuxppc-dev@lists.ozlabs.org >>> Signed-off-by: Rob Herring >>> --- >>> drivers/i2c/busses/i2c-powermac.c | 15 --- >>> drivers/i2c/muxes/i2c-mux-gpmux.c | 4 ++-- >>> 2 files changed, 10 insertions(+), 9 deletions(-) >>> >>> diff --git a/drivers/i2c/busses/i2c-powermac.c >>> b/drivers/i2c/busses/i2c-powermac.c >>> index f2a2067525ef..b706fd136ca5 100644 >>> --- a/drivers/i2c/busses/i2c-powermac.c >>> +++ b/drivers/i2c/busses/i2c-powermac.c >>> @@ -390,7 +390,6 @@ static int i2c_powermac_probe(struct platform_device >>> *dev) >>> struct pmac_i2c_bus *bus = dev_get_platdata(>dev); >>> struct device_node *parent = NULL; >> >> Lose the initializer... > > That's pretty much unrelated though. I disagree. If you remove the need for the initializer, it's very much related to also remove the initializer. > I'd have to write "Also, remove > the unnecessary parent pointer init" in the commit message and we all > know "Also" is a clue for belongs in a separate patch. How about: "This makes the parent pointer initializer redundant, lose it." See, no "Also" in there, and no separate patch needed. Or don't mention it at all. Cheers, Peter
[PATCH] mtd: Convert to using %pOFn instead of device_node.name
In preparation to remove the node name pointer from struct device_node, convert printf users to use the %pOFn format specifier. Cc: David Woodhouse Cc: Brian Norris Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: linux-...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Rob Herring --- One more %pOFn conversion for MTD. Please apply to MTD tree. drivers/mtd/devices/powernv_flash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/devices/powernv_flash.c b/drivers/mtd/devices/powernv_flash.c index 33593122e49b..22f753e555ac 100644 --- a/drivers/mtd/devices/powernv_flash.c +++ b/drivers/mtd/devices/powernv_flash.c @@ -212,7 +212,7 @@ static int powernv_flash_set_driver_info(struct device *dev, * Going to have to check what details I need to set and how to * get them */ - mtd->name = of_get_property(dev->of_node, "name", NULL); + mtd->name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn", dev->of_node); mtd->type = MTD_NORFLASH; mtd->flags = MTD_WRITEABLE; mtd->size = size; -- 2.17.1
[PATCH] of: make PowerMac cache node search conditional on CONFIG_PPC_PMAC
Cache nodes under the cpu node(s) is PowerMac specific according to the comment above, so make the code enforce that. Signed-off-by: Rob Herring --- drivers/of/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/of/base.c b/drivers/of/base.c index 466e3c8582f0..cadcb470198a 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -1963,7 +1963,7 @@ struct device_node *of_find_next_cache_node(const struct device_node *np) /* OF on pmac has nodes instead of properties named "l2-cache" * beneath CPU nodes. */ - if (!strcmp(np->type, "cpu")) + if (IS_ENABLED(CONFIG_PPC_PMAC) && !strcmp(np->type, "cpu")) for_each_child_of_node(np, child) if (!strcmp(child->type, "cache")) return child; -- 2.17.1
Re: [PATCH] i2c: Convert to using %pOFn instead of device_node.name
On Wed, Aug 29, 2018 at 1:03 PM Peter Rosin wrote: > > On 2018-08-28 03:52, Rob Herring wrote: > > In preparation to remove the node name pointer from struct device_node, > > convert printf users to use the %pOFn format specifier. > > > > Cc: Benjamin Herrenschmidt > > Cc: Paul Mackerras > > Cc: Michael Ellerman > > Cc: Peter Rosin > > Cc: linux-...@vger.kernel.org > > Cc: linuxppc-dev@lists.ozlabs.org > > Signed-off-by: Rob Herring > > --- > > drivers/i2c/busses/i2c-powermac.c | 15 --- > > drivers/i2c/muxes/i2c-mux-gpmux.c | 4 ++-- > > 2 files changed, 10 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/i2c/busses/i2c-powermac.c > > b/drivers/i2c/busses/i2c-powermac.c > > index f2a2067525ef..b706fd136ca5 100644 > > --- a/drivers/i2c/busses/i2c-powermac.c > > +++ b/drivers/i2c/busses/i2c-powermac.c > > @@ -390,7 +390,6 @@ static int i2c_powermac_probe(struct platform_device > > *dev) > > struct pmac_i2c_bus *bus = dev_get_platdata(>dev); > > struct device_node *parent = NULL; > > Lose the initializer... That's pretty much unrelated though. I'd have to write "Also, remove the unnecessary parent pointer init" in the commit message and we all know "Also" is a clue for belongs in a separate patch. Rob
Re: [PATCH 2/3] mm/cow: optimise pte dirty/accessed bits handling in fork
On Tue, Aug 28, 2018 at 4:20 AM Nicholas Piggin wrote: > > fork clears dirty/accessed bits from new ptes in the child. This logic > has existed since mapped page reclaim was done by scanning ptes when > it may have been quite important. Today with physical based pte > scanning, there is less reason to clear these bits. Can you humor me, and make the dirty/accessed bit patches separate? There is actually a difference wrt the dirty bit: if we unmap an area with dirty pages, we have to do the special synchronous flush. So a clean page in the virtual mapping is _literally_ cheaper to have. > This eliminates a major source of faults powerpc/radix requires to set > dirty/accessed bits in ptes, speeding up a fork/exit microbenchmark by > about 5% on POWER9 (16600 -> 17500 fork/execs per second). I don't think the dirty bit matters. The accessed bit I think may be worth keeping, so by all means remove the mkold. Linus
Re: Not able to boot cuImage for the target board with MPC8270 processor
Thanks for your reply. Yes, both the options are enabled in the kernel configuration for my board as seen below. CONFIG_PPC_EARLY_DEBUG=y CONFIG_PPC_EARLY_DEBUG_CPM=y # CONFIG_PPC_EARLY_DEBUG_MEMCONS is not set CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0x11a80 -- Sent from: http://linuxppc.10917.n7.nabble.com/linuxppc-dev-f3.html
Re: Not able to boot cuImage for the target board with MPC8270 processor
Yes, both these config options are enabled as you can see from the below details from my .config file. CONFIG_PPC_EARLY_DEBUG=y CONFIG_PPC_EARLY_DEBUG_CPM=y # CONFIG_PPC_EARLY_DEBUG_MEMCONS is not set CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0x11a80 -- Sent from: http://linuxppc.10917.n7.nabble.com/linuxppc-dev-f3.html
[PATCH v2 5/6] net/wan/fsl_ucc_hdlc: GUMR for non tsa mode
The following bits in the GUMR is changed for non
tsa mode: CDS, CTSP and CTSS are set to zero.
When set, there is no tx interrupts from the controller.
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index be5b0096af3b..248f1f5bcd04 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -97,6 +97,13 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
if (priv->tsa) {
uf_info->tsa = 1;
uf_info->ctsp = 1;
+ uf_info->cds = 1;
+ uf_info->ctss = 1;
+ }
+ else {
+ uf_info->cds = 0;
+ uf_info->ctsp = 0;
+ uf_info->ctss = 0;
}
/* This sets HPM register in CMXUCR register which configures a
--
2.13.6
[PATCH v2 6/6] net/wan/fsl_ucc_hdlc: tx timeout handler
Added tx timerout handler. This helps
when troubleshooting.
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 248f1f5bcd04..629ef5049d27 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -1002,11 +1002,15 @@ static const struct dev_pm_ops uhdlc_pm_ops = {
#define HDLC_PM_OPS NULL
#endif
+static void uhdlc_tx_timeout(struct net_device *ndev) {
+ netdev_err(ndev, "%s\n", __FUNCTION__);
+}
static const struct net_device_ops uhdlc_ops = {
.ndo_open = uhdlc_open,
.ndo_stop = uhdlc_close,
.ndo_start_xmit = hdlc_start_xmit,
.ndo_do_ioctl = uhdlc_ioctl,
+ .ndo_tx_timeout = uhdlc_tx_timeout,
};
static int ucc_hdlc_probe(struct platform_device *pdev)
@@ -1125,6 +1129,7 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
hdlc = dev_to_hdlc(dev);
dev->tx_queue_len = 16;
dev->netdev_ops = _ops;
+ dev->watchdog_timeo = 2*HZ;
hdlc->attach = ucc_hdlc_attach;
hdlc->xmit = ucc_hdlc_tx;
netif_napi_add(dev, _priv->napi, ucc_hdlc_poll, 32);
--
2.13.6
[PATCH v2 4/6] net/wan/fsl_ucc_hdlc: hmask
Ability to set hmask in the device-tree,
which can be used to change address
filtering of packets.
Signed-off-by: David Gounaris
---
Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 6 ++
drivers/net/wan/fsl_ucc_hdlc.c | 5 -
drivers/net/wan/fsl_ucc_hdlc.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
index 03c741602c6d..6d2dd8a31482 100644
--- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
@@ -98,6 +98,12 @@ The property below is dependent on fsl,tdm-interface:
usage: optional for tdm interface
value type:
Definition : Internal loopback connecting on TDM layer.
+- fsl,hmask
+ usage: optional
+ Value type:
+ Definition: HDLC address recognition. Set to zero to disable
+ address filtering of packets:
+ fsl,hmask = /bits/ 16 <0x>;
Example for tdm interface:
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 0f703d7be5e0..be5b0096af3b 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -263,7 +263,7 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
iowrite16be(MAX_FRAME_LENGTH, >ucc_pram->mflr);
iowrite16be(DEFAULT_RFTHR, >ucc_pram->rfthr);
iowrite16be(DEFAULT_RFTHR, >ucc_pram->rfcnt);
- iowrite16be(DEFAULT_ADDR_MASK, >ucc_pram->hmask);
+ iowrite16be(priv->hmask, >ucc_pram->hmask);
iowrite16be(DEFAULT_HDLC_ADDR, >ucc_pram->haddr1);
iowrite16be(DEFAULT_HDLC_ADDR, >ucc_pram->haddr2);
iowrite16be(DEFAULT_HDLC_ADDR, >ucc_pram->haddr3);
@@ -1097,6 +1097,9 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
if (ret)
goto free_utdm;
}
+
+ if (of_property_read_u16(np, "fsl,hmask", _priv->hmask))
+ uhdlc_priv->hmask = DEFAULT_ADDR_MASK;
ret = uhdlc_init(uhdlc_priv);
if (ret) {
diff --git a/drivers/net/wan/fsl_ucc_hdlc.h b/drivers/net/wan/fsl_ucc_hdlc.h
index c21134c1f180..b99fa2f1cd99 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.h
+++ b/drivers/net/wan/fsl_ucc_hdlc.h
@@ -106,6 +106,7 @@ struct ucc_hdlc_private {
unsigned short encoding;
unsigned short parity;
+ unsigned short hmask;
u32 clocking;
spinlock_t lock;/* lock for Tx BD and Tx buffer */
#ifdef CONFIG_PM
--
2.13.6
[PATCH v2 3/6] net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER
This patch is to avoid discarding ethernet packets when using HDLC_ETH protocol. Signed-off-by: David Gounaris --- drivers/net/wan/fsl_ucc_hdlc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c index c8e526bf1130..0f703d7be5e0 100644 --- a/drivers/net/wan/fsl_ucc_hdlc.c +++ b/drivers/net/wan/fsl_ucc_hdlc.c @@ -376,6 +376,10 @@ static netdev_tx_t ucc_hdlc_tx(struct sk_buff *skb, struct net_device *dev) dev->stats.tx_bytes += skb->len; break; + case ARPHRD_ETHER: + dev->stats.tx_bytes += skb->len; + break; + default: dev->stats.tx_dropped++; dev_kfree_skb(skb); @@ -513,6 +517,8 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit) break; case ARPHRD_PPP: + case ARPHRD_ETHER: + length -= HDLC_CRC_SIZE; skb = dev_alloc_skb(length); -- 2.13.6
[PATCH v2 2/6] net/wan/fsl_ucc_hdlc: allow PARITY_CRC16_PR0_CCITT parity
Signed-off-by: David Gounaris --- drivers/net/wan/fsl_ucc_hdlc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c index 5cf6dcba039c..c8e526bf1130 100644 --- a/drivers/net/wan/fsl_ucc_hdlc.c +++ b/drivers/net/wan/fsl_ucc_hdlc.c @@ -781,7 +781,8 @@ static int ucc_hdlc_attach(struct net_device *dev, unsigned short encoding, if (parity != PARITY_NONE && parity != PARITY_CRC32_PR1_CCITT && - parity != PARITY_CRC16_PR1_CCITT) + parity != PARITY_CRC16_PR1_CCITT && + parity != PARITY_CRC16_PR0_CCITT) return -EINVAL; priv->encoding = encoding; -- 2.13.6
[PATCH v2 0/6] Ethernet over hdlc
Here is what has been changed in v2 after the review comments. v2-0001: Using UCC_MAX_NUM v2-0002: Unchanged v2-0003: Changed commit message v2-0004: Adding fsl,hmask into the dt instead of changing the default value. v2-0005: Unchanged v2-0006: Unchanged Adding robh...@kernel.org for comments regarding dt. Best Regards David Gounaris David Gounaris (6): net/wan/fsl_ucc_hdlc: allow ucc index up to 7 net/wan/fsl_ucc_hdlc: allow PARITY_CRC16_PR0_CCITT parity net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER net/wan/fsl_ucc_hdlc: hmask net/wan/fsl_ucc_hdlc: GUMR for non tsa mode net/wan/fsl_ucc_hdlc: tx timeout handler .../devicetree/bindings/soc/fsl/cpm_qe/network.txt | 6 + drivers/net/wan/fsl_ucc_hdlc.c | 28 +++--- drivers/net/wan/fsl_ucc_hdlc.h | 1 + 3 files changed, 32 insertions(+), 3 deletions(-) -- 2.13.6
[PATCH v2 1/6] net/wan/fsl_ucc_hdlc: allow ucc index up to 7
There is a need to allow higher indexes to be
able to support MPC83xx platforms. (UCC1-UCC8)
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 33df76405b86..5cf6dcba039c 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -1016,7 +1016,7 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
}
ucc_num = val - 1;
- if ((ucc_num > 3) || (ucc_num < 0)) {
+ if ((ucc_num > UCC_MAX_NUM - 1) || (ucc_num < 0)) {
dev_err(>dev, ": Invalid UCC num\n");
return -EINVAL;
}
--
2.13.6
Re: Not able to boot cuImage for the target board with MPC8270 processor
Le 29/08/2018 à 13:14, sgosavi1 a écrit : Hi Everyone, Recently I took up the activity of switching from Linux kernel version 2.16.17.6 to version 4.15.13 for our target board that supports MPC8270 PowerPC processor. As I understand the new kernel version mandates the use of a device tree in the kernel source to describe the target board. I took "pq2fads.dts" as a reference device tree file to port the kernel for our target board. The U-boot version 1.1.4 that we currently use does not support passing of device tree to kernel but passes the board information structure used by the older kernel version we have been using so far. As suggested in the new kernel documentation I created a "cuImage.pq2fads" kernel image which has the device tree and boot wrapper code embedded in the image to support booting the kernel with older U-boot. However I am unable to see any debug output after the dump from U-boot below. U-Boot 1.1.4 (Aug 2 2018 - 06:27:35) MPC8260 Reset Status: Check Stop, External Soft, External Hard MPC8260 Clock Configuration - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300 - dfbrg 1, corecnf 0x1a, busdf 5, cpmdf 1, plldf 0, pllmf 5 - vco_out 394515000, scc_clk 98628750, brg_clk 24657187 - cpu_clk 26301, cpm_clk 197257500, bus_clk 65752500 CPU: MPC8260 (HiP7 Rev 14, Mask 1.0 1K49M) at 263.010 MHz Board: Emerson MPC8270 CCB Init SRAM, CAN, DOC... UPMA done. Setting up UPMB Rev B or Higher CPU Board I2C: ready DRAM: 128 MB FLASH: 16 MB In:serial Out: serial Err: serial Net: FCC1 ETHERNET, FCC2 ETHERNET Press to STOP AUTOBOOT!:autoboot in 2 seconds ## Booting image at ffc0 ... Image Name: Linux-4.15.13 Created: 2018-08-29 10:45:39 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1166748 Bytes = 1.1 MB Load Address: 0040 Entry Point: 004007a4 Verifying Checksum ... OK Uncompressing Kernel Image ... OK I also checked the kernel dump at location associated with "_log_buf" symbol in the System.map file in RAM but did not get any debug info. Please can anyone suggest if I am missing something here and how can I get the debug output on my serial console during bootup. Have you selected CONFIG_PPC_EARLY_DEBUG (and probably CONFIG_PPC_EARLY_DEBUG_CPM) ? Christophe Thanks, Sachin. -- Sent from: http://linuxppc.10917.n7.nabble.com/linuxppc-dev-f3.html
Not able to boot cuImage for the target board with MPC8270 processor
Hi Everyone, Recently I took up the activity of switching from Linux kernel version 2.16.17.6 to version 4.15.13 for our target board that supports MPC8270 PowerPC processor. As I understand the new kernel version mandates the use of a device tree in the kernel source to describe the target board. I took "pq2fads.dts" as a reference device tree file to port the kernel for our target board. The U-boot version 1.1.4 that we currently use does not support passing of device tree to kernel but passes the board information structure used by the older kernel version we have been using so far. As suggested in the new kernel documentation I created a "cuImage.pq2fads" kernel image which has the device tree and boot wrapper code embedded in the image to support booting the kernel with older U-boot. However I am unable to see any debug output after the dump from U-boot below. U-Boot 1.1.4 (Aug 2 2018 - 06:27:35) MPC8260 Reset Status: Check Stop, External Soft, External Hard MPC8260 Clock Configuration - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300 - dfbrg 1, corecnf 0x1a, busdf 5, cpmdf 1, plldf 0, pllmf 5 - vco_out 394515000, scc_clk 98628750, brg_clk 24657187 - cpu_clk 26301, cpm_clk 197257500, bus_clk 65752500 CPU: MPC8260 (HiP7 Rev 14, Mask 1.0 1K49M) at 263.010 MHz Board: Emerson MPC8270 CCB Init SRAM, CAN, DOC... UPMA done. Setting up UPMB Rev B or Higher CPU Board I2C: ready DRAM: 128 MB FLASH: 16 MB In:serial Out: serial Err: serial Net: FCC1 ETHERNET, FCC2 ETHERNET Press to STOP AUTOBOOT!:autoboot in 2 seconds ## Booting image at ffc0 ... Image Name: Linux-4.15.13 Created: 2018-08-29 10:45:39 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1166748 Bytes = 1.1 MB Load Address: 0040 Entry Point: 004007a4 Verifying Checksum ... OK Uncompressing Kernel Image ... OK I also checked the kernel dump at location associated with "_log_buf" symbol in the System.map file in RAM but did not get any debug info. Please can anyone suggest if I am missing something here and how can I get the debug output on my serial console during bootup. Thanks, Sachin. -- Sent from: http://linuxppc.10917.n7.nabble.com/linuxppc-dev-f3.html
Re: [RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
On Wed, Aug 29, 2018 at 09:32:23AM +0200, Krzysztof Kozlowski wrote:
> After commit faa16bc404d7 ("lib: Use existing define with
> polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
> directory thus any other user of this code should define proper include
> path.
>
> This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
>
> In file included from
> ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
> from ../arch/powerpc/boot/decompress.c:42:
> ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error:
> linux/crc32poly.h: No such file or directory
>
> Reported-by: Michal Kubecek
> Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Only compile tested.
> ---
> arch/powerpc/boot/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 0fb96c26136f..ba4182fb185d 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -63,7 +63,7 @@ ifeq ($(call cc-option-yn, -fstack-protector),y)
> BOOTCFLAGS += -fno-stack-protector
> endif
>
> -BOOTCFLAGS += -I$(objtree)/$(obj) -I$(srctree)/$(obj)
> +BOOTCFLAGS += -I$(objtree)/$(obj) -I$(srctree)/$(obj) -I$(srctree)/include
>
> DTC_FLAGS?= -p 1024
>
> --
> 2.7.4
>
With this patch 4.19-rc1 builds and boots on ppc64le. Thank you.
Tested-by: Michal Kubecek
[RFC PATCH] powerpc/64/module: REL32 relocation range check
The recent module relocation overflow crash demonstrated that we
have no range checking on REL32 relative relocations. This patch
implements a basic check, the same kernel that previously oopsed
and rebooted now continues with some of these errors when loading
the module:
module_64: x_tables: REL32 527703503449812 out of range!
Question is whether other relocations (ADDR32, REL16, TOC16, etc.)
should also have overflow checks.
---
arch/powerpc/kernel/module_64.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index a2636c250b7b..2a2fb656d23b 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -678,7 +678,14 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
case R_PPC64_REL32:
/* 32 bits relative (used by relative exception tables)
*/
- *(u32 *)location = value - (unsigned long)location;
+ /* Convert value to relative */
+ value -= (unsigned long)location;
+ if (value + 0x8000 > 0x) {
+ pr_err("%s: REL32 %li out of range!\n",
+ me->name, (long int)value);
+ return -ENOEXEC;
+ }
+ *(u32 *)location = value;
break;
case R_PPC64_TOCSAVE:
--
2.18.0
Re: [PATCH] fsl/qe: ucc: copy and paste bug in ucc_get_tdm_sync_shift()
On Mon, Jun 04, 2018 at 02:06:45PM +0200, Mathieu Malaterre wrote: > Where did the original go ? > > https://patchwork.ozlabs.org/patch/868158/ > > Btw, we still haven't pushed a patch for this bug. regards, dan carpenter
[PATCH] fsl: remove redundant pointer 'priv'
From: Colin Ian King
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
---
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(_dev->dev);
-
irq = dpio_dev->irqs[0];
error = devm_request_irq(_dev->dev,
irq->msi_desc->irq,
--
2.17.1
Re: [PATCH] soc: Convert to using %pOFn instead of device_node.name
Am Dienstag, 28. August 2018, 03:52:44 CEST schrieb Rob Herring: > In preparation to remove the node name pointer from struct device_node, > convert printf users to use the %pOFn format specifier. > drivers/soc/rockchip/pm_domains.c | 44 +++ For the Rockchip-part Acked-by: Heiko Stuebner
Re: [PATCH] sched/topology: Use Identity node only if required
On Wed, Aug 29, 2018 at 10:43:48AM +0200, Peter Zijlstra wrote: > DIE(j) should be: > > cpu_cpu_mask(j) := cpumask_of_node(cpu_to_node(j)) FWIW, I was expecting that to be topology_core_cpumask(), so I'm a little confused myself just now. > and NODE(j) should be: > > \Union_k cpumask_of_node(k) ; where node_distance(j,k) <= > node_distance(0,0) > > which, _should_ reduce to: > > cpumask_of_node(j) > > and thus DIE and NODE _should_ be the same here. > > So what's going sideways?
RE: [PATCH] soc: Convert to using %pOFn instead of device_node.name
From: Rob Herring Date: 2018年8月28日 9:53 > To: linux-ker...@vger.kernel.org > Cc: Qiang Zhao ; Leo Li ; Andy > Gross ; David Brown ; Heiko > Stuebner ; Thierry Reding ; > Jonathan Hunter ; Santosh Shilimkar > ; linuxppc-dev@lists.ozlabs.org; > linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org > Subject: [PATCH] soc: Convert to using %pOFn instead of device_node.name > > In preparation to remove the node name pointer from struct device_node, > convert printf users to use the %pOFn format specifier. > > Cc: Qiang Zhao > Cc: Li Yang > Cc: Andy Gross > Cc: David Brown > Cc: Heiko Stuebner > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Santosh Shilimkar > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring > --- > drivers/soc/dove/pmu.c| 8 +++--- > drivers/soc/fsl/qe/qe_tdm.c | 4 +-- > drivers/soc/qcom/apr.c| 2 +- > drivers/soc/rockchip/pm_domains.c | 44 +++ > drivers/soc/tegra/pmc.c | 12 - > drivers/soc/ti/knav_dma.c | 8 +++--- > drivers/soc/ti/knav_qmss_queue.c | 8 +++--- > 7 files changed, 43 insertions(+), 43 deletions(-) For qe_tdm part Acked-by: Qiang Zhao
Re: [PATCH] sched/topology: Use Identity node only if required
On Fri, Aug 10, 2018 at 09:45:33AM -0700, Srikar Dronamraju wrote:
> available: 4 nodes (0-3)
> node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39 64 65 66 67 68 69 70 71
> 96 97 98 99 100 101 102 103 128 129 130 131 132 133 134 135 160 161 162 163
> 164 165 166 167 192 193 194 195 196 197 198 199 224 225 226 227 228 229 230
> 231 256 257 258 259 260 261 262 263 288 289 290 291 292 293 294 295
> node 0 size: 536888 MB
> node 0 free: 533582 MB
> node 1 cpus: 24 25 26 27 28 29 30 31 56 57 58 59 60 61 62 63 88 89 90 91 92
> 93 94 95 120 121 122 123 124 125 126 127 152 153 154 155 156 157 158 159 184
> 185 186 187 188 189 190 191 216 217 218 219 220 221 222 223 248 249 250 251
> 252 253 254 255 280 281 282 283 284 285 286 287
> node 1 size: 502286 MB
> node 1 free: 501283 MB
> node 2 cpus: 16 17 18 19 20 21 22 23 48 49 50 51 52 53 54 55 80 81 82 83 84
> 85 86 87 112 113 114 115 116 117 118 119 144 145 146 147 148 149 150 151 176
> 177 178 179 180 181 182 183 208 209 210 211 212 213 214 215 240 241 242 243
> 244 245 246 247 272 273 274 275 276 277 278 279
> node 2 size: 503054 MB
> node 2 free: 502854 MB
> node 3 cpus: 8 9 10 11 12 13 14 15 40 41 42 43 44 45 46 47 72 73 74 75 76 77
> 78 79 104 105 106 107 108 109 110 111 136 137 138 139 140 141 142 143 168 169
> 170 171 172 173 174 175 200 201 202 203 204 205 206 207 232 233 234 235 236
> 237 238 239 264 265 266 267 268 269 270 271 296 297 298 299 300 301 302 303
> node 3 size: 503310 MB
> node 3 free: 498465 MB
> node distances:
> node 0 1 2 3
> 0: 10 40 40 40
> 1: 40 10 40 40
> 2: 40 40 10 40
> 3: 40 40 40 10
>
> Extracting the contents of dmesg using sched_debug kernel parameter
>
> CPU0 attaching NULL sched-domain.
> CPU1 attaching NULL sched-domain.
>
>
> CPU302 attaching NULL sched-domain.
> CPU303 attaching NULL sched-domain.
> BUG: arch topology borken
> the DIE domain not a subset of the NODE domain
^ CLUE!!
but nowhere did you show what it thinks the DIE mask is.
> CPU0 attaching sched-domain(s):
>domain-2: sdA, span=0-303 level=NODE
> groups: sg=sgL 0:{
> span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295
> cap=81920 }, sgM 8:{
> span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303
> cap=81920 }, sdN 16:{
> span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279
> cap=73728 }, sgO 24:{
> span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287
> cap=73728 }
> CPU1 attaching sched-domain(s):
>domain-2: sdB, span=0-303 level=NODE
> [ 367.739387] groups: sg=sgL 0:{
> span=0-7,32-39,64-71,96-103,128-135,160-167,192-199,224-231,256-263,288-295
> cap=81920 }, sgM 8:{
> span=8-15,40-47,72-79,104-111,136-143,168-175,200-207,232-239,264-271,296-303
> cap=81920 }, sdN 16:{
> span=16-23,48-55,80-87,112-119,144-151,176-183,208-215,240-247,272-279
> cap=73728 }, sgO 24:{
> span=24-31,56-63,88-95,120-127,152-159,184-191,216-223,248-255,280-287
> cap=73728 }
You forgot to provide the rest of it... what's domain-[01] look like?
DIE(j) should be:
cpu_cpu_mask(j) := cpumask_of_node(cpu_to_node(j))
and NODE(j) should be:
\Union_k cpumask_of_node(k) ; where node_distance(j,k) <=
node_distance(0,0)
which, _should_ reduce to:
cpumask_of_node(j)
and thus DIE and NODE _should_ be the same here.
So what's going sideways?
Re: [RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
On Wed, 29 Aug 2018 at 10:06, Mathieu Malaterre wrote:
>
> On Wed, Aug 29, 2018 at 9:59 AM Krzysztof Kozlowski wrote:
> >
> > On Wed, 29 Aug 2018 at 09:32, Krzysztof Kozlowski wrote:
> > >
> > > After commit faa16bc404d7 ("lib: Use existing define with
> > > polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
> > > directory thus any other user of this code should define proper include
> > > path.
> > >
> > > This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
> > >
> > > In file included from
> > > ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
> > > from ../arch/powerpc/boot/decompress.c:42:
> > > ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error:
> > > linux/crc32poly.h: No such file or directory
> > >
> > > Reported-by: Michal Kubecek
> >
> > Reported earlier by Kbuild:
> > https://lkml.org/lkml/2018/8/23/47
> >
> > for the credits:
> > Reported-by: kbuild test robot
>
> Technically Meelis reported it earlier:
>
> https://lkml.org/lkml/2018/8/22/365
>
> ;)
Oh, right... so for the full credits:
Reported-by: Meelis Roos
Best regards,
Krzysztof
Re: [PATCH] powerpc: disable support for relative ksymtab references
On Wed, 29 Aug 2018 08:47:53 +0200 Ard Biesheuvel wrote: > The newly added code that emits ksymtab entries as pairs of 32-bit > relative references interacts poorly with the way powerpc lays out > its address space: when a module exports a per-CPU variable, the > primary module region covering the ksymtab entry -and thus the 32-bit > relative reference- is too far away from the actual per-CPU variable's > base address (to which the per-CPU offsets are applied to obtain the > respective address of each CPU's copy), resulting in corruption when > the module loader attempts to resolve symbol references of modules > that are loaded on top and link to the exported per-CPU symbol. > > So let's disable this feature on powerpc. Even though it implements > CONFIG_RELOCATABLE, it does not implement CONFIG_RANDOMIZE_BASE and > so KASLR kernels (which are the main target of the feature) do not > exist on powerpc anyway. Let's go with this for now. We have a bit more work to do with module loader, linker, percpu, or all of the above. Thanks everyone. Linus can you merge this? I think Michael is on vacation this week and things are pretty crashy without it here. Don't need to call him off the beach for it. Thanks, Nick > > Reported-by: Andreas Schwab > Suggested-by: Nicholas Piggin > Signed-off-by: Ard Biesheuvel > --- > arch/powerpc/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index db0b6eebbfa5..a80669209155 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -177,7 +177,6 @@ config PPC > select HAVE_ARCH_KGDB > select HAVE_ARCH_MMAP_RND_BITS > select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT > - select HAVE_ARCH_PREL32_RELOCATIONS > select HAVE_ARCH_SECCOMP_FILTER > select HAVE_ARCH_TRACEHOOK > select HAVE_CBPF_JITif !PPC64 > -- > 2.17.1 >
Re: [RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
On Wed, Aug 29, 2018 at 9:59 AM Krzysztof Kozlowski wrote:
>
> On Wed, 29 Aug 2018 at 09:32, Krzysztof Kozlowski wrote:
> >
> > After commit faa16bc404d7 ("lib: Use existing define with
> > polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
> > directory thus any other user of this code should define proper include
> > path.
> >
> > This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
> >
> > In file included from
> > ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
> > from ../arch/powerpc/boot/decompress.c:42:
> > ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error:
> > linux/crc32poly.h: No such file or directory
> >
> > Reported-by: Michal Kubecek
>
> Reported earlier by Kbuild:
> https://lkml.org/lkml/2018/8/23/47
>
> for the credits:
> Reported-by: kbuild test robot
Technically Meelis reported it earlier:
https://lkml.org/lkml/2018/8/22/365
;)
Re: [PATCH 2/2] sched/topology: Expose numa_mask set/clear functions to arch
On Fri, Aug 10, 2018 at 10:30:19PM +0530, Srikar Dronamraju wrote:
> With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> sched domain") scheduler introduces an new numa level. However on shared
> lpars like powerpc, this extra sched domain creation can lead to
> repeated rcu stalls, sometimes even causing unresponsive systems on
> boot. On such stalls, it was noticed that init_sched_groups_capacity()
> (sg != sd->groups is always true).
>
> INFO: rcu_sched self-detected stall on CPU
> 1-: (240039 ticks this GP) idle=c32/1/4611686018427387906
> softirq=782/782 fqs=80012
> (t=240039 jiffies g=6272 c=6271 q=263040)
> NMI backtrace for cpu 1
> --- interrupt: 901 at __bitmap_weight+0x70/0x100
> LR = __bitmap_weight+0x78/0x100
> [c0832132f9b0] [c09bb738] __func__.61127+0x0/0x20 (unreliable)
> [c0832132fa00] [c016c178] build_sched_domains+0xf98/0x13f0
> [c0832132fb30] [c016d73c] partition_sched_domains+0x26c/0x440
> [c0832132fc20] [c01ee284] rebuild_sched_domains_locked+0x64/0x80
> [c0832132fc50] [c01f11ec] rebuild_sched_domains+0x3c/0x60
> [c0832132fc80] [c007e1c4] topology_work_fn+0x24/0x40
> [c0832132fca0] [c0126704] process_one_work+0x1a4/0x470
> [c0832132fd30] [c0126a68] worker_thread+0x98/0x540
> [c0832132fdc0] [c012f078] kthread+0x168/0x1b0
> [c0832132fe30] [c000b65c]
> ret_from_kernel_thread+0x5c/0x80
>
> Similar problem was earlier also reported at
> https://lwn.net/ml/linux-kernel/20180512100233.GB3738@osiris/
>
> Allow arch to set and clear masks corresponding to numa sched domain.
What this Changelog fails to do is explain the problem and motivate why
this is the right solution.
As-is, this reads like, something's buggered, I changed this random thing
and it now works.
So what is causing that domain construction error?
[PATCH] powerpc/time: Calculate proper wday
to_tm() hardcodes wday to -1 as "No-one uses the day of the week". But recently rtc driver ds1307 does care and tries to correct wday. Add wday calculation(stolen from rtc_time64_to_tm) to to_tm() to please ds1307. Signed-off-by: Joakim Tjernlund --- arch/powerpc/kernel/time.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index fe6f3a285455..f4a09ee01944 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -1160,6 +1160,9 @@ void to_tm(int tim, struct rtc_time * tm) day = tim / SECDAY; hms = tim % SECDAY; + /* day of the week, 1970-01-01 was a Thursday */ + tm->tm_wday = (day + 4) % 7; + /* Hours, minutes, seconds are easy */ tm->tm_hour = hms / 3600; tm->tm_min = (hms % 3600) / 60; @@ -1180,11 +1183,6 @@ void to_tm(int tim, struct rtc_time * tm) /* Days are what is left over (+1) from all that. */ tm->tm_mday = day + 1; - - /* -* No-one uses the day of the week. -*/ - tm->tm_wday = -1; } EXPORT_SYMBOL(to_tm); -- 2.16.4
Re: [RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
On Wed, 29 Aug 2018 at 09:32, Krzysztof Kozlowski wrote:
>
> After commit faa16bc404d7 ("lib: Use existing define with
> polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
> directory thus any other user of this code should define proper include
> path.
>
> This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
>
> In file included from
> ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
> from ../arch/powerpc/boot/decompress.c:42:
> ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error:
> linux/crc32poly.h: No such file or directory
>
> Reported-by: Michal Kubecek
Reported earlier by Kbuild:
https://lkml.org/lkml/2018/8/23/47
for the credits:
Reported-by: kbuild test robot
Best regards,
Krzysztof
[RFT] powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ
After commit faa16bc404d7 ("lib: Use existing define with
polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
directory thus any other user of this code should define proper include
path.
This fixes the build error on powerpc with CONFIG_KERNEL_XZ:
In file included from
../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
from ../arch/powerpc/boot/decompress.c:42:
../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error:
linux/crc32poly.h: No such file or directory
Reported-by: Michal Kubecek
Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
Signed-off-by: Krzysztof Kozlowski
---
Only compile tested.
---
arch/powerpc/boot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 0fb96c26136f..ba4182fb185d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -63,7 +63,7 @@ ifeq ($(call cc-option-yn, -fstack-protector),y)
BOOTCFLAGS += -fno-stack-protector
endif
-BOOTCFLAGS += -I$(objtree)/$(obj) -I$(srctree)/$(obj)
+BOOTCFLAGS += -I$(objtree)/$(obj) -I$(srctree)/$(obj) -I$(srctree)/include
DTC_FLAGS ?= -p 1024
--
2.7.4
Re: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
On Wed, 2018-08-29 at 09:18 +0200, Christophe LEROY wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> Le 29/08/2018 à 04:54, Qiang Zhao a écrit :
> > From: David Gounaris
> > Date: 2018/8/28 19:09
> > > Subject: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
> > >
> > > Set default HMASK to 0x to use
> > > promiscuous mode in the hdlc controller.
>
> Why do you need to do that ?
>
> An HDLC frame encapsulating Ethernet should look like:
>
> HDLC Frame includes:
> – Opening Flag 7E hex
> – Address field FF hex
> – Control field 03 hex
> – Information field Original Ethernet Packet, 1522 octets max.
> – FCS CRC16 (2 bytes)
> – Closing Flag 7E hex
In our case the Eth frame starts directly after the Opening Flag so
there is no FF address field.
>
> What do you mean by 'promiscuous mode' ?
Just that we don't want any address filtering of packets. I don't think this
would
be a problem for pure HDLC frames either, do you?
>
> In any case, should a filter mask be changed for promiscuous mode, I
> believe the change should be done at the time you enter promiscuous
> mode, not at all time.
>
> Christophe
>
> > >
> > > Signed-off-by: David Gounaris
> > > ---
> > > drivers/net/wan/fsl_ucc_hdlc.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/wan/fsl_ucc_hdlc.h
> > > b/drivers/net/wan/fsl_ucc_hdlc.h
> > > index c21134c1f180..5bc3d1a6ca6e 100644
> > > --- a/drivers/net/wan/fsl_ucc_hdlc.h
> > > +++ b/drivers/net/wan/fsl_ucc_hdlc.h
> > > @@ -134,7 +134,7 @@ struct ucc_hdlc_private {
> > >
> > > #define HDLC_HEAD_MASK 0x
> > > #define DEFAULT_HDLC_HEAD 0xff44
> > > -#define DEFAULT_ADDR_MASK 0x00ff
> > > +#define DEFAULT_ADDR_MASK 0x
> > > #define DEFAULT_HDLC_ADDR 0x00ff
> > >
> > > #define BMR_GBL0x2000
> > > --
> >
> > It is not proper to set default HMASK to 0x, how about to add a new
> > property standing for hmask into device tree,
> > If get this property from dtb, then set it with the value from dtb,
> > otherwise, set it with default HMASK ox00ff?
> >
> > Best Regards
> > Qiang Zhao
> >
Re: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
Le 29/08/2018 à 04:54, Qiang Zhao a écrit :
From: David Gounaris
Date: 2018/8/28 19:09
Subject: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
Set default HMASK to 0x to use
promiscuous mode in the hdlc controller.
Why do you need to do that ?
An HDLC frame encapsulating Ethernet should look like:
HDLC Frame includes:
– Opening Flag 7E hex
– Address field FF hex
– Control field 03 hex
– Information field Original Ethernet Packet, 1522 octets max.
– FCS CRC16 (2 bytes)
– Closing Flag 7E hex
What do you mean by 'promiscuous mode' ?
In any case, should a filter mask be changed for promiscuous mode, I
believe the change should be done at the time you enter promiscuous
mode, not at all time.
Christophe
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.h b/drivers/net/wan/fsl_ucc_hdlc.h
index c21134c1f180..5bc3d1a6ca6e 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.h
+++ b/drivers/net/wan/fsl_ucc_hdlc.h
@@ -134,7 +134,7 @@ struct ucc_hdlc_private {
#define HDLC_HEAD_MASK0x
#define DEFAULT_HDLC_HEAD 0xff44
-#define DEFAULT_ADDR_MASK 0x00ff
+#define DEFAULT_ADDR_MASK 0x
#define DEFAULT_HDLC_ADDR 0x00ff
#define BMR_GBL 0x2000
--
It is not proper to set default HMASK to 0x, how about to add a new
property standing for hmask into device tree,
If get this property from dtb, then set it with the value from dtb, otherwise,
set it with default HMASK ox00ff?
Best Regards
Qiang Zhao
Re: [PATCH v7 1/2] powerpc: Detect the presence of big-cores via "ibm,thread-groups"
On Wed, 2018-08-29 at 17:04 +1000, Michael Neuling wrote: > > +What: /sys/devices/system/cpu/cpu[0-9]+/small_core_siblings > > Shouldn't we put this in the topology/ subdir with with the other items like > it? Also, please follow the same format as *_sibilings files topology/ where they are just a mask (this patch currently has it as a comma separated list). Mikey
Re: [PATCH 1/6] net/wan/fsl_ucc_hdlc: allow ucc index up to 4
Le 28/08/2018 à 15:34, Christophe LEROY a écrit :
Le 28/08/2018 à 13:09, David Gounaris a écrit :
There is a need to allow higher indexes to be
able to support MPC83xx platforms. (UCC1-UCC5)
As far as I can see, MPC8358 has 8 UCCs (ref
https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/powerquicc-processors/powerquicc-ii-pro/powerquicc-ii-pro-processor-with-ddr2-tdm-pci-security-usb-quicc-engine-with-1-gb-ethernet-utopia:MPC8358E)
Indeed, the code should use UCC_MAX_NUM which is defined in
include/soc/fsl/qe/ucc.h
Christophe
Christophe
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c
b/drivers/net/wan/fsl_ucc_hdlc.c
index 5f0366a125e2..3c0e0a1d19ba 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -1015,7 +1015,7 @@ static int ucc_hdlc_probe(struct platform_device
*pdev)
}
ucc_num = val - 1;
- if ((ucc_num > 3) || (ucc_num < 0)) {
+ if ((ucc_num > 4) || (ucc_num < 0)) {
dev_err(>dev, ": Invalid UCC num\n");
return -EINVAL;
}
Re: [PATCH v7 1/2] powerpc: Detect the presence of big-cores via "ibm,thread-groups"
> +What:/sys/devices/system/cpu/cpu[0-9]+/small_core_siblings Shouldn't we put this in the topology/ subdir with with the other items like it? Mikey
[PATCH] powerpc: disable support for relative ksymtab references
The newly added code that emits ksymtab entries as pairs of 32-bit relative references interacts poorly with the way powerpc lays out its address space: when a module exports a per-CPU variable, the primary module region covering the ksymtab entry -and thus the 32-bit relative reference- is too far away from the actual per-CPU variable's base address (to which the per-CPU offsets are applied to obtain the respective address of each CPU's copy), resulting in corruption when the module loader attempts to resolve symbol references of modules that are loaded on top and link to the exported per-CPU symbol. So let's disable this feature on powerpc. Even though it implements CONFIG_RELOCATABLE, it does not implement CONFIG_RANDOMIZE_BASE and so KASLR kernels (which are the main target of the feature) do not exist on powerpc anyway. Reported-by: Andreas Schwab Suggested-by: Nicholas Piggin Signed-off-by: Ard Biesheuvel --- arch/powerpc/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index db0b6eebbfa5..a80669209155 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -177,7 +177,6 @@ config PPC select HAVE_ARCH_KGDB select HAVE_ARCH_MMAP_RND_BITS select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT - select HAVE_ARCH_PREL32_RELOCATIONS select HAVE_ARCH_SECCOMP_FILTER select HAVE_ARCH_TRACEHOOK select HAVE_CBPF_JITif !PPC64 -- 2.17.1
