* [PATCH kernel v2 6/6] KVM: PPC: Remove redundand permission bits removal
From: Alexey Kardashevskiy @ 2018-09-10 8:29 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, David Gibson, kvm-ppc, Aneesh Kumar K.V,
Paul Mackerras, Alex Williamson
In-Reply-To: <20180910082912.13255-1-aik@ozlabs.ru>
The kvmppc_gpa_to_ua() helper itself takes care of the permission
bits in the TCE and yet every single caller removes them.
This changes semantics of kvmppc_gpa_to_ua() so it takes TCEs
(which are GPAs + TCE permission bits) to make the callers simpler.
This should cause no behavioural change.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v2:
* %s/kvmppc_gpa_to_ua/kvmppc_tce_to_ua/g
---
arch/powerpc/include/asm/kvm_ppc.h | 2 +-
arch/powerpc/kvm/book3s_64_vio.c | 12 ++++--------
arch/powerpc/kvm/book3s_64_vio_hv.c | 22 +++++++++-------------
3 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index 2f5d431..38d0328 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -194,7 +194,7 @@ 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_gpa_to_ua(struct kvm *kvm, unsigned long gpa,
+extern long kvmppc_tce_to_ua(struct kvm *kvm, unsigned long tce,
unsigned long *ua, unsigned long **prmap);
extern void kvmppc_tce_put(struct kvmppc_spapr_tce_table *tt,
unsigned long idx, unsigned long tce);
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 8231b17..c0c64d1 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -378,8 +378,7 @@ static long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *stt,
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))
+ if (kvmppc_tce_to_ua(stt->kvm, tce, &ua, NULL))
return H_TOO_HARD;
list_for_each_entry_rcu(stit, &stt->iommu_tables, next) {
@@ -552,8 +551,7 @@ long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
idx = srcu_read_lock(&vcpu->kvm->srcu);
- if ((dir != DMA_NONE) && kvmppc_gpa_to_ua(vcpu->kvm,
- tce & ~(TCE_PCI_READ | TCE_PCI_WRITE), &ua, NULL)) {
+ if ((dir != DMA_NONE) && kvmppc_tce_to_ua(vcpu->kvm, tce, &ua, NULL)) {
ret = H_PARAMETER;
goto unlock_exit;
}
@@ -614,7 +612,7 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
return ret;
idx = srcu_read_lock(&vcpu->kvm->srcu);
- if (kvmppc_gpa_to_ua(vcpu->kvm, tce_list, &ua, NULL)) {
+ if (kvmppc_tce_to_ua(vcpu->kvm, tce_list, &ua, NULL)) {
ret = H_TOO_HARD;
goto unlock_exit;
}
@@ -649,9 +647,7 @@ long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
}
tce = be64_to_cpu(tce);
- if (kvmppc_gpa_to_ua(vcpu->kvm,
- tce & ~(TCE_PCI_READ | TCE_PCI_WRITE),
- &ua, NULL))
+ if (kvmppc_tce_to_ua(vcpu->kvm, tce, &ua, NULL))
return H_PARAMETER;
list_for_each_entry_lockless(stit, &stt->iommu_tables, next) {
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
index adf3b21..389dac1 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -110,8 +110,7 @@ static long kvmppc_rm_tce_validate(struct kvmppc_spapr_tce_table *stt,
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))
+ if (kvmppc_tce_to_ua(stt->kvm, tce, &ua, NULL))
return H_TOO_HARD;
list_for_each_entry_lockless(stit, &stt->iommu_tables, next) {
@@ -180,10 +179,10 @@ void kvmppc_tce_put(struct kvmppc_spapr_tce_table *stt,
}
EXPORT_SYMBOL_GPL(kvmppc_tce_put);
-long kvmppc_gpa_to_ua(struct kvm *kvm, unsigned long gpa,
+long kvmppc_tce_to_ua(struct kvm *kvm, unsigned long tce,
unsigned long *ua, unsigned long **prmap)
{
- unsigned long gfn = gpa >> PAGE_SHIFT;
+ unsigned long gfn = tce >> PAGE_SHIFT;
struct kvm_memory_slot *memslot;
memslot = search_memslots(kvm_memslots(kvm), gfn);
@@ -191,7 +190,7 @@ long kvmppc_gpa_to_ua(struct kvm *kvm, unsigned long gpa,
return -EINVAL;
*ua = __gfn_to_hva_memslot(memslot, gfn) |
- (gpa & ~(PAGE_MASK | TCE_PCI_READ | TCE_PCI_WRITE));
+ (tce & ~(PAGE_MASK | TCE_PCI_READ | TCE_PCI_WRITE));
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
if (prmap)
@@ -200,7 +199,7 @@ long kvmppc_gpa_to_ua(struct kvm *kvm, unsigned long gpa,
return 0;
}
-EXPORT_SYMBOL_GPL(kvmppc_gpa_to_ua);
+EXPORT_SYMBOL_GPL(kvmppc_tce_to_ua);
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
static long iommu_tce_xchg_rm(struct mm_struct *mm, struct iommu_table *tbl,
@@ -389,8 +388,7 @@ long kvmppc_rm_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
return ret;
dir = iommu_tce_direction(tce);
- if ((dir != DMA_NONE) && kvmppc_gpa_to_ua(vcpu->kvm,
- tce & ~(TCE_PCI_READ | TCE_PCI_WRITE), &ua, NULL))
+ if ((dir != DMA_NONE) && kvmppc_tce_to_ua(vcpu->kvm, tce, &ua, NULL))
return H_PARAMETER;
entry = ioba >> stt->page_shift;
@@ -492,7 +490,7 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
*/
struct mm_iommu_table_group_mem_t *mem;
- if (kvmppc_gpa_to_ua(vcpu->kvm, tce_list, &ua, NULL))
+ if (kvmppc_tce_to_ua(vcpu->kvm, tce_list, &ua, NULL))
return H_TOO_HARD;
mem = mm_iommu_lookup_rm(vcpu->kvm->mm, ua, IOMMU_PAGE_SIZE_4K);
@@ -508,7 +506,7 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
* We do not require memory to be preregistered in this case
* so lock rmap and do __find_linux_pte_or_hugepte().
*/
- if (kvmppc_gpa_to_ua(vcpu->kvm, tce_list, &ua, &rmap))
+ if (kvmppc_tce_to_ua(vcpu->kvm, tce_list, &ua, &rmap))
return H_TOO_HARD;
rmap = (void *) vmalloc_to_phys(rmap);
@@ -542,9 +540,7 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
unsigned long tce = be64_to_cpu(((u64 *)tces)[i]);
ua = 0;
- if (kvmppc_gpa_to_ua(vcpu->kvm,
- tce & ~(TCE_PCI_READ | TCE_PCI_WRITE),
- &ua, NULL))
+ if (kvmppc_tce_to_ua(vcpu->kvm, tce, &ua, NULL))
return H_PARAMETER;
list_for_each_entry_lockless(stit, &stt->iommu_tables, next) {
--
2.11.0
^ permalink raw reply related
* RE: [PATCH 2/3] Documentation: dt: binding: fsl: update property description for RCPM
From: Ran Wang @ 2018-09-10 8:44 UTC (permalink / raw)
To: Scott Wood, Leo Li, Rob Herring, Mark Rutland
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-pm@lists.linux-foundation.org
In-Reply-To: <c19f11e200258297dbe5a61392a4bbc1e937d7c3.camel@buserror.net>
SGkgU2NvdHQsDQoNCk9uIDIwMTgvOS84IDQ6MjMsIFNjb3R0IFdvb2Qgd3JvdGU6DQo+IA0KPiBP
biBGcmksIDIwMTgtMDgtMzEgYXQgMTE6NTIgKzA4MDAsIFJhbiBXYW5nIHdyb3RlOg0KPiA+ICtP
cHRpb25hbCBwcm9wZXJ0aWVzOg0KPiA+ICsgLSBiaWctZW5kaWFuIDogSW5kaWNhdGUgUkNQTSBy
ZWdpc3RlcnMgaXMgYmlnLWVuZGlhbi4gQSBSQ1BNIG5vZGUNCj4gPiArICAgdGhhdCBkb2Vzbid0
IGhhdmUgdGhpcyBwcm9wZXJ0eSB3aWxsIGJlIHJlZ2FyZGVkIGFzIGxpdHRsZS1lbmRpYW4uDQo+
IA0KPiBZb3UndmUganVzdCBicm9rZW4gYWxsIHRoZSBleGlzdGluZyBwb3dlcnBjIGRldmljZSB0
cmVlcyB0aGF0IGFyZSBiaWctZW5kaWFuDQo+IGFuZCBoYXZlIG5vIGJpZy1lbmRpYW4gcHJvcGVy
dHkuDQoNClllcywgcG93ZXJwYyBSQ1BNIGRyaXZlciAoYXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xf
cmNwbS5jKSB3aWxsIG5vdCByZWZlcg0KdG8gYmlnLWVuZGlhbi4gSG93ZXZlciwgSSB0aGluayBp
ZiBMYXllcnNjYXBlIFJDUE0gZHJpdmVyIHVzZSBkaWZmZXJlbnQgY29tcGF0aWJsZQ0KaWQgKHN1
Y2ggYXMgJyBmc2wscW9yaXEtcmNwbS0yLjInKSwgaXQgbWlnaHQgYmUgc2FmZS4gSXMgdGhhdCBP
Sz8NCg0KPiA+ICsgLSA8cHJvcGVydHkgJ2NvbXBhdGlibGUnIHN0cmluZyBvZiBjb25zdW1lciBk
ZXZpY2U+IDogVGhpcyBzdHJpbmcNCj4gPiArICAgaXMgcmVmZXJyZWQgYnkgUkNQTSBkcml2ZXIg
dG8ganVkZ2UgaWYgdGhlIGNvbnN1bWVyIChzdWNoIGFzIGZsZXggdGltZXIpDQo+ID4gKyAgIGlz
IGFibGUgdG8gYmUgcmVnYXJkcyBhcyB3YWtldXAgc291cmNlIG9yIG5vdCwgc3VjaCBhcw0KPiA+
ICsgJ2ZzbCxsczEwMTJhLQ0KPiA+IGZ0bScuDQo+ID4gKyAgIEZ1cnRoZXIsIHRoaXMgcHJvcGVy
dHkgd2lsbCBjYXJyeSB0aGUgYml0IG1hc2sgaW5mbyB0byBjb250cm9sDQo+ID4gKyAgIGNvcmVz
cG9uZGluZyB3YWtlIHVwIHNvdXJjZS4NCj4gDQo+IFdoYXQgd2lsbCB5b3UgZG8gaWYgdGhlcmUg
YXJlIG11bHRpcGxlIGluc3RhbmNlcyBvZiBhIGRldmljZSB3aXRoIHRoZSBzYW1lDQo+IGNvbXBh
dGlibGUsIGFuZCBkaWZmZXJlbnQgd2FrZXVwIGJpdHM/ICANCg0KWW91IGdvdCBtZSEgVGhpcyBp
cyBhIHByb2JsZW0gaW4gY3VycmVudCB2ZXJzaW9uLiBXZWxsLCB3ZSBoYXZlIHRvIGRlY291cGxl
IHdha2UgdXANCnNvdXJjZSBJUCBhbmQgUkNQTSBkcml2ZXIuIFRoYXQncyB3aHkgSSBhZGQgYSBw
bGF0X3BtIGRyaXZlciB0byBwcmV2ZW50IHdha2UgdXAgSVANCmtub3dpbmcgYW55IGluZm9ybWF0
aW9uIG9mIFJDUE0uIFNvIGluIGN1cnJlbnQgY29udGV4dCwgb25lIGlkZWEgY29tZSB0byBtZSBp
cyB0bw0KcmVkZXNpZ24gcHJvcGVydHkgJyBmc2wsbHMxMDEyYS1mdG0gPSA8MHgyMDAwMD47Jywg
Y2hhbmdlIHRvICdmc2wsbHMxMDEyYS1mdG0gPSA8JmZ0bTAgMHgyMDAwMD47Jw0KV2hhdCBkbyB5
b3Ugc2F5PyBBbmQgY291bGQgeW91IHRlbGwgbWUgd2hpY2ggQVBJIEkgY2FuIHVzZSB0byBjaGVj
ayBpZiB0aGF0IGRldmljZSdzDQpuYW1lIGlzIGZ0bTAgKGZvciBleGFtcGxlIHdlIHdhbnQgdG8g
ZmluZCBhIG5vZGUgZnRtMDogZnRtQDI5ZDAwMCk/DQoNCj5QbHVzLCBpdCdzIGFuIGF3a3dhcmQg
ZGVzaWduIGluDQo+IGdlbmVyYWwsIGFuZCB5b3UgZG9uJ3QgZGVzY3JpYmUgd2hhdCB0aGUgdmFs
dWUgYWN0dWFsbHkgbWVhbnMgKGJpdHMgaW4gd2hpY2gNCj4gcmVnaXN0ZXI/KS4gDQoNClllcywg
SSBhZG1pdCBteSBkZXNpZ24gbG9va3MgdWdseSBhbmQgbm90IGZsZXhpYmxlIGFuZCBleHRlbnNp
YmxlIGVub3VnaC4gSG93ZXZlciwgZm9yIGFib3ZlIHJlYXNvbiwgDQpkbyB5b3UgaGF2ZSBhbnkg
Z29vZCBpZGVhLCBwbGVhc2U/IDopDQoNCkFzIHRvIHRoZSByZWdpc3RlciBpbmZvcm1hdGlvbiwg
SSBjYW4gZXhwbGFpbiBoZXJlIGluIGRldGFpbHMgKHdpbGwgYWRkIHRvIGNvbW1pdA0KbWVzc2Fn
ZSBvZiBuZXh0IHZlcnNpb24pOiBUaGVyZSBpcyBhIFJDUE0gSFcgYmxvY2sgd2hpY2ggaGFzIHJl
Z2lzdGVyIG5hbWVkIElQUERFWFBDUi4NCkl0IGNvbnRyb2xzIHdoZXRoZXIgcHJldmVudCBjZXJ0
YWluIElQIChzdWNoIGFzIHRpbWVyLCB1c2IsIGV0YykgZnJvbSBlbnRlcmluZyBsb3cNCnBvd2Vy
IG1vZGUgd2hlbiBzeXN0ZW0gc3VzcGVuZGVkLiBTbyBpdCdzIG5lY2Vzc2FyeSB0byBwcm9ncmFt
IGl0IGlmIHdlIHdhbnQgb25lDQpvZiB0aG9zZSBJUCB3b3JrIGFzIGEgd2FrZXVwIHNvdXJjZS4g
SG93ZXZlciwgZGlmZmVyZW50IExheWVyc2NhcGUgU29DcyBoYXZlIGRpZmZlcmVudCBiaXQgdnMu
DQpJUCBtYXBwaW5nICBsYXlvdXQuIFNvIEkgaGF2ZSB0byByZWNvcmQgdGhpcyBpbmZvcm1hdGlv
biBpbiBkZXZpY2UgdHJlZSBhbmQgZmV0Y2hlZCBieSBSQ1BNIGRyaXZlcg0KZGlyZWN0bHkuDQoN
CkRvIEkgbmVlZCB0byBsaXN0IGFsbCBTb0MncyBtYXBwaW5nIGluZm9ybWF0aW9uIGluIHRoaXMg
YmluZGluZyBkb2MgZm9yIHJlZmVyZW5jZT8NCg0KPldoYXQgd2FzIHdyb25nIHdpdGggdGhlIGV4
aXN0aW5nIGJpbmRpbmc/ICANCg0KVGhlcmUgd2FzIG9uZSB2ZXJzaW9uIG9mIFJDUE0gcGF0Y2gg
d2hpY2ggcmVxdWlyaW5nIHByb3BlcnR5ICdmc2wsI3JjcG0td2FrZXVwLWNlbGxzJyBidXQgd2Fz
IG5vdA0KYWNjZXB0ZWQgYnkgdXBzdHJlYW0gZmluYWxseS4gTm93IHdlIHdpbGwgbm8gbmVlZCBp
dCBhbnkgbG9uZ2VyIGR1ZSB0byBuZXcgZGVzaWduIGFsbG93IGNhc2Ugb2YgbXVsdGlwbGUNClJD
UE0gZGV2aWNlcyBleGlzdGluZyBjYXNlLg0KDQo+QWx0ZXJuYXRpdmVseSwgdXNlIHRoZSBjbG9j
ayBiaW5kaW5ncy4NCg0KU29ycnkgSSBkaWRuJ3QgZ2V0IHlvdXIgcG9pbnQuDQoNCj4gPiAtDQo+
ID4gLUV4YW1wbGU6DQo+ID4gLQlscHVhcnQwOiBzZXJpYWxAMjk1MDAwMCB7DQo+ID4gLQkJY29t
cGF0aWJsZSA9ICJmc2wsbHMxMDIxYS1scHVhcnQiOw0KPiA+IC0JCXJlZyA9IDwweDAgMHgyOTUw
MDAwIDB4MCAweDEwMDA+Ow0KPiA+IC0JCWludGVycnVwdHMgPSA8R0lDX1NQSSA4MCBJUlFfVFlQ
RV9MRVZFTF9ISUdIPjsNCj4gPiAtCQljbG9ja3MgPSA8JnN5c2Nsaz47DQo+ID4gLQkJY2xvY2st
bmFtZXMgPSAiaXBnIjsNCj4gPiAtCQlmc2wscmNwbS13YWtldXAgPSA8JnJjcG0gMHgwIDB4NDAw
MDAwMDA+Ow0KPiA+ICsJCWJpZy1lbmRpYW47DQo+ID4gKwkJZnNsLGxzMTAxMmEtZnRtID0gPDB4
MjAwMDA+Ow0KPiA+ICsJCWZzbCxwZmUgPSA8MHhmMDAwMDAyMD47DQo+IA0KPiBmc2wscGZlIGlz
IG5vdCBkb2N1bWVudGVkLg0KDQpwZmUgcGF0Y2ggaXMgbm90IHVwc3RyZWFtIHlldCwgd2lsbCBy
ZW1vdmUgaXQuDQoNClJlZ2FyZHMsDQpSYW4NCg0KPiAtU2NvdHQNCg0K
^ permalink raw reply
* Re: [RFC 0/4] Virtio uses DMA API for all devices
From: Gerd Hoffmann @ 2018-09-10 8:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jiandi An, brijesh.singh, srikar, Michael S. Tsirkin,
Benjamin Herrenschmidt, Will Deacon, virtualization, paulus,
elfring, Anshuman Khandual, robh, jean-philippe.brucker, mpe,
thomas.lendacky, marc.zyngier, linuxram, david, linuxppc-dev,
linux-kernel, joe, jiandi.an, robin.murphy, haren
In-Reply-To: <20180910061947.GA30666@infradead.org>
> > this to set the VIRTIO_F_IOMMU_PLATFORM flag. But for example
> > QEMU has the use of iommu_platform attribute disabled for virtio-gpu
> > device. So would also like to move towards not having to specify
> > the VIRTIO_F_IOMMU_PLATFORM flag.
>
> Specifying VIRTIO_F_IOMMU_PLATFORM is the right thing for your
> platform given that you can't directly use physical addresses.
> Please fix qemu so that virtio-gpu works with VIRTIO_F_IOMMU_PLATFORM.
This needs both host and guest side changes btw.
Guest side patch is in drm-misc (a3b815f09bb8) and should land in the
next merge window.
Host side patches are here:
https://git.kraxel.org/cgit/qemu/log/?h=sirius/virtio-gpu-iommu
Should also land in the next qemu version.
cheers,
Gerd
^ permalink raw reply
* [PATCH 0/2] powerpc: Clang build fixes
From: Joel Stanley @ 2018-09-10 8:57 UTC (permalink / raw)
To: linuxppc-dev, Anton Blanchard
Two fixes to get us closer to building with clang. With a one patch[1]
on top of clang master I can build and boot a powernv kernel:
$ make ARCH=powerpc powernv_defconfig
$ ./scripts/config -e PPC_DISABLE_WERROR -d FTRACE -d BTRFS_FS -d MD_RAID456
$ make CC=/scratch/joel/llvm-build/bin/clang-8 CLANG_TRIPLE=powerpc64le-linux-gnu -j128
$ qemu-system-ppc64 -M powernv -m 3G -nographic -kernel zImage.epapr \
-L ~/skiboot/ -initrd ~/rootfs.cpio.xz
Linux version 4.19.0-rc3-00003-g728b25f26bce (joel@ozrom3) (clang version 8.0.0 (trunk 341773)) #12 SMP Mon Sep 10 17:32:05 ACST 2018
The DISABLE_WERROR is due to clang's -Wduplicate-decl-specifier. Some
macros we have in arch/powerpc/include/asm/uaccess.h warn on 'const
typeof(var)', where as the GCC version doesn't. Anton did fix this a
while ago, but the fix was 'reverted' to resolve some sparse warnings.
I think we should re-apply Anton's patch[2].
[1] https://reviews.llvm.org/D50965
[2] http://git.kernel.org/torvalds/c/b91c1e3e7a6f22a6b898e345b745b6a43273c973
Joel Stanley (2):
powerpc/boot: Fix crt0.S syntax for clang
powerpc/boot: Ensure _zimage_start is a weak symbol
arch/powerpc/boot/crt0.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/2] powerpc/boot: Fix crt0.S syntax for clang
From: Joel Stanley @ 2018-09-10 8:57 UTC (permalink / raw)
To: linuxppc-dev, Anton Blanchard
In-Reply-To: <20180910085714.4834-1-joel@jms.id.au>
Clang's assembler does not like the syntax of the cmpdi:
arch/powerpc/boot/crt0.S:168:22: error: unexpected modifier on variable reference
cmpdi 12,RELACOUNT@l
^
arch/powerpc/boot/crt0.S:168:11: error: unknown operand
cmpdi 12,RELACOUNT@l
^
Enclosing RELACOUNT in () makes it is happy. Tested with GCC 8 and Clang
8 (trunk).
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/powerpc/boot/crt0.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index dcf2f15e6797..ace3f3c64620 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -165,7 +165,7 @@ p_base: mflr r10 /* r10 now points to runtime addr of p_base */
ld r13,8(r11) /* get RELA pointer in r13 */
b 11f
10: addis r12,r12,(-RELACOUNT)@ha
- cmpdi r12,RELACOUNT@l
+ cmpdi r12,(RELACOUNT)@l
bne 11f
ld r8,8(r11) /* get RELACOUNT value in r8 */
11: addi r11,r11,16
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] powerpc/boot: Ensure _zimage_start is a weak symbol
From: Joel Stanley @ 2018-09-10 8:57 UTC (permalink / raw)
To: linuxppc-dev, Anton Blanchard
In-Reply-To: <20180910085714.4834-1-joel@jms.id.au>
When building with clang crt0's _zimage_start is not marked weak, which
breaks the build when linking the kernel image:
$ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$
0000000000000058 g .text 0000000000000000 _zimage_start
ld: arch/powerpc/boot/wrapper.a(crt0.o): in function '_zimage_start':
(.text+0x58): multiple definition of '_zimage_start';
arch/powerpc/boot/pseries-head.o:(.text+0x0): first defined here
Clang requires the .weak directive to appear after the symbol is
declared. The binutils manual says:
This directive sets the weak attribute on the comma separated list of
symbol names. If the symbols do not already exist, they will be
created.
So it appears this is different with clang. The only reference I could
see for this was an OpenBSD mailing list post[1].
Changing it to be after the declaration fixes building with Clang, and
still works with GCC.
$ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$
0000000000000058 w .text 0000000000000000 _zimage_start
[1] https://groups.google.com/forum/#!topic/fa.openbsd.tech/PAgKKen2YCY
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/powerpc/boot/crt0.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index ace3f3c64620..41c6d03d6e2d 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -47,8 +47,8 @@ p_end: .long _end
p_pstack: .long _platform_stack_top
#endif
- .weak _zimage_start
.globl _zimage_start
+ .weak _zimage_start
_zimage_start:
.globl _zimage_start_lib
_zimage_start_lib:
--
2.17.1
^ permalink raw reply related
* RE: [PATCH 3/3] soc: fsl: add RCPM driver
From: Ran Wang @ 2018-09-10 9:09 UTC (permalink / raw)
To: Scott Wood, Leo Li, Rob Herring, Mark Rutland
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-pm@lists.linux-foundation.org
In-Reply-To: <86101ce0f4201d05510e57d74cafe8c665b8e5d4.camel@buserror.net>
SGkgU2NvdHQsDQoNCk9uIDIwMTgvOS84IDE4OjE2LCBTY290dCBXb29kIHdyb3RlOg0KPiANCj4g
T24gRnJpLCAyMDE4LTA4LTMxIGF0IDExOjUyICswODAwLCBSYW4gV2FuZyB3cm90ZToNCj4gPiBU
aGUgTlhQJ3MgUW9ySVEgUHJvY2Vzc29ycyBiYXNlZCBvbiBBUk0gQ29yZSBoYXZlIFJDUE0gbW9k
dWxlIChSdW4NCj4gPiBDb250cm9sIGFuZCBQb3dlciBNYW5hZ2VtZW50KSwgd2hpY2ggcGVyZm9y
bXMgYWxsIGRldmljZS1sZXZlbCB0YXNrcw0KPiA+IGFzc29jaWF0ZWQgd2l0aCBwb3dlciBtYW5h
Z2VtZW50IHN1Y2ggYXMgd2FrZXVwIHNvdXJjZSBjb250cm9sLg0KPiA+DQo+ID4gVGhpcyBkcml2
ZXIgZGVwZW5kcyBvbiBGU0wgcGxhdGZvcm0gUE0gZHJpdmVyIGZyYW1ld29yayB3aGljaCBoZWxw
IHRvDQo+ID4gaXNvbGF0ZSB1c2VyIGFuZCBQTSBzZXJ2aWNlIHByb3ZpZGVyIChzdWNoIGFzIFJD
UE0gZHJpdmVyKS4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IENoZW5odWkgWmhhbyA8Y2hlbmh1
aS56aGFvQG54cC5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogWWluZyBaaGFuZyA8eWluZy56aGFu
ZzIyNDU1QG54cC5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogUmFuIFdhbmcgPHJhbi53YW5nXzFA
bnhwLmNvbT4NCj4gPiAtLS0NCj4gPiAgZHJpdmVycy9zb2MvZnNsL0tjb25maWcgICB8ICAgIDYg
KysNCj4gPiAgZHJpdmVycy9zb2MvZnNsL01ha2VmaWxlICB8ICAgIDEgKw0KPiA+ICBkcml2ZXJz
L3NvYy9mc2wvbHMtcmNwbS5jIHwgIDE1Mw0KPiA+ICsrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKw0KPiA+ICAzIGZpbGVzIGNoYW5nZWQsIDE2MCBpbnNlcnRpb25z
KCspLCAwIGRlbGV0aW9ucygtKSAgY3JlYXRlIG1vZGUNCj4gPiAxMDA2NDQgZHJpdmVycy9zb2Mv
ZnNsL2xzLXJjcG0uYw0KPiANCj4gSXMgdGhlcmUgYSByZWFzb24gd2h5IHRoaXMgaXMgTFMtc3Bl
Y2lmaWMsIG9yIGNvdWxkIGl0IGJlIHVzZWQgd2l0aCBQUEMgUkNQTQ0KPiBibG9ja3M/DQoNClRo
ZXkgaGF2ZSBkaWZmZXJlbnQgU1cgYXJjaCBkZXNpZ24gb24gbG93IHBvd2VyIG9wZXJhdGlvbjog
UFBDIFJDUE0NCmRyaXZlciBoYXMgdGFrZW4gY2FyZSBvZiBtb3N0IHRoaW5ncyBvZiBzdXNwZW5k
IGVudGVyICYgZXhpdC4gQW5kIExTIFJDUE0gZHJpdmVyDQp3aWxsIG9ubHkgaGFuZGxlIHdha2V1
cCBzb3VyY2UgY29uZmlndXJlIGFuZCBsZWZ0IHJlc3Qgd29yayB0byBzeXN0ZW0gZmlybXdhcmUN
CnRvIGRvLiBTbyB5b3UgbWlnaHQgYmUgYXdhcmUgdGhhdCBMUyBSQ1BNIHdpbGwgb25seSBnZXQg
Y2FsbCB3aGVuZXZlciBwbGF0X3BtDQpkcml2ZXIgQVBJIGlzIGNhbGxlZCByYXRoZXIgdGhhbiBz
eXN0ZW0gc3VzcGVuZCBiZWdpbiB3aGVyZS4NCg0KPiANCj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVy
cy9zb2MvZnNsL0tjb25maWcgYi9kcml2ZXJzL3NvYy9mc2wvS2NvbmZpZyBpbmRleA0KPiA+IDY1
MTc0MTIuLjg4MjMzMGQgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9zb2MvZnNsL0tjb25maWcN
Cj4gPiArKysgYi9kcml2ZXJzL3NvYy9mc2wvS2NvbmZpZw0KPiA+IEBAIC0zMCwzICszMCw5IEBA
IGNvbmZpZyBGU0xfUExBVF9QTQ0KPiA+ICAJICBoYXZlIHRvIGtub3cgdGhlIGltcGxlbWVudCBk
ZXRhaWxzIG9mIHdha2V1cCBmdW5jdGlvbiBpdCByZXF1aXJlLg0KPiA+ICAJICBCZXNpZGVzLCBp
dCBpcyBhbHNvIGVhc3kgZm9yIHNlcnZpY2Ugc2lkZSB0byB1cGdyYWRlIGl0cyBsb2dpYw0KPiA+
IHdoZW4NCj4gPiAgCSAgZGVzaWduIGNoYW5nZWQgYW5kIHJlbWFpbiB1c2VyIHNpZGUgdW5jaGFu
Z2VkLg0KPiA+ICsNCj4gPiArY29uZmlnIExTX1JDUE0NCj4gPiArCWJvb2wgIkZyZWVzY2FsZSBS
Q1BNIHN1cHBvcnQiDQo+ID4gKwlkZXBlbmRzIG9uIChGU0xfUExBVF9QTSkNCj4gDQo+IFdoeSBp
cyB0aGlzIHBhcmVudGhlc2l6ZWQ/DQoNCkJlY2F1c2Ugd2UnZCBsaWtlIHRvIGRlY291cGxlIFJD
UE0gZHJpdmVyIGFuZCBpdHMgdXNlci4NCkJlbmVmaXQgaXMgdGhhdCB3aWxsIGFsbG93IHVzZXIg
ZG9lc24ndCBoYXZlIHRvIGtub3cgd2hvIHdpbGwgc2VydmUgaXQgZm9yIHNvbWUgUE0NCmZlYXR1
cmVzIChzdWNoIGFzIHdha2UgdXAgc291cmNlIGNvbnRyb2wpLCBhbmQgcHJvdmlkZSBzb21lIGtp
bmQgb2YgZmxleGliaWxpdHkgd2hlbg0KZWl0aGVyIFJDTVAgb3IgdXNlciBkcml2ZXIgZXZvbHZl
IGluIHRoZSBmdXR1cmUuIFNvIEkgYWRkIGEgcGxhdF9wbSBkcml2ZXIgdG8gcHJldmVudA0Kd2Fr
ZSB1cCBJUCBrbm93aW5nIGFueSBpbmZvcm1hdGlvbiBvZiBSQ1BNLg0KDQpSZWdhcmRzLA0KUmFu
DQoNCj4gDQo+IC1TY290dA0KDQo=
^ permalink raw reply
* RE: [PATCH 1/3] soc: fsl: add Platform PM driver QorIQ platforms
From: Ran Wang @ 2018-09-10 9:26 UTC (permalink / raw)
To: Scott Wood, Leo Li, Rob Herring, Mark Rutland
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-pm@lists.linux-foundation.org
In-Reply-To: <cad8c585fb415959e7ade8b500278c2c5e070873.camel@buserror.net>
SGkgU2NvdHQsDQoNCk9uIDIwMTgvOS84IDQ6MzUsIFNjb3R0IFdvb2Qgd3JvdGU6DQo+IA0KPiBP
biBGcmksIDIwMTgtMDgtMzEgYXQgMTE6NTIgKzA4MDAsIFJhbiBXYW5nIHdyb3RlOg0KPiA+IFRo
aXMgZHJpdmVyIGlzIHRvIHByb3ZpZGUgYSBpbmRlcGVuZGVudCBmcmFtZXdvcmsgZm9yIFBNIHNl
cnZpY2UNCj4gPiBwcm92aWRlciBhbmQgY29uc3VtZXIgdG8gY29uZmlndXJlIHN5c3RlbSBsZXZl
bCB3YWtlIHVwIGZlYXR1cmUuIEZvcg0KPiA+IGV4YW1wbGUsIFJDUE0gZHJpdmVyIGNvdWxkIHJl
Z2lzdGVyIGEgY2FsbGJhY2sgZnVuY3Rpb24gb24gdGhpcw0KPiA+IHBsYXRmb3JtIGZpcnN0LCBh
bmQgRmxleCB0aW1lciBkcml2ZXIgd2hvIHdhbnQgdG8gZW5hYmxlIHRpbWVyIHdha2UgdXANCj4g
PiBmZWF0dXJlLCB3aWxsIGNhbGwgZ2VuZXJpYyBBUEkgcHJvdmlkZWQgYnkgdGhpcyBwbGF0Zm9y
bSBkcml2ZXIsIGFuZA0KPiA+IHRoZW4gaXQgd2lsbCB0cmlnZ2VyIFJDUE0gZHJpdmVyIHRvIGRv
IGl0LiBUaGUgYmVuZWZpdCBpcyB0byBpc29sYXRlDQo+ID4gdGhlIHVzZXIgYW5kIHNlcnZpY2Us
IHN1Y2ggYXMgZmxleCB0aW1lciBkcml2ZXIgd2lsbCBub3QgaGF2ZSB0byBrbm93DQo+ID4gdGhl
IGltcGxlbWVudCBkZXRhaWxzIG9mIHdha2V1cCBmdW5jdGlvbiBpdCByZXF1aXJlLiBCZXNpZGVz
LCBpdCBpcw0KPiA+IGFsc28gZWFzeSBmb3Igc2VydmljZSBzaWRlIHRvIHVwZ3JhZGUgaXRzIGxv
Z2ljIHdoZW4gZGVzaWduIGlzIGNoYW5nZWQNCj4gPiBhbmQgcmVtYWluIHVzZXIgc2lkZSB1bmNo
YW5nZWQuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBSYW4gV2FuZyA8cmFuLndhbmdfMUBueHAu
Y29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL3NvYy9mc2wvS2NvbmZpZyAgIHwgICAxNCArKysr
Kw0KPiA+ICBkcml2ZXJzL3NvYy9mc2wvTWFrZWZpbGUgIHwgICAgMSArDQo+ID4gIGRyaXZlcnMv
c29jL2ZzbC9wbGF0X3BtLmMgfCAgMTQ0DQo+ID4gKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrDQo+ID4gIGluY2x1ZGUvc29jL2ZzbC9wbGF0X3BtLmggfCAgIDIy
ICsrKysrKysNCj4gPiAgNCBmaWxlcyBjaGFuZ2VkLCAxODEgaW5zZXJ0aW9ucygrKSwgMCBkZWxl
dGlvbnMoLSkgIGNyZWF0ZSBtb2RlDQo+ID4gMTAwNjQ0IGRyaXZlcnMvc29jL2ZzbC9wbGF0X3Bt
LmMgIGNyZWF0ZSBtb2RlIDEwMDY0NA0KPiA+IGluY2x1ZGUvc29jL2ZzbC9wbGF0X3BtLmgNCj4g
Pg0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3NvYy9mc2wvS2NvbmZpZyBiL2RyaXZlcnMvc29j
L2ZzbC9LY29uZmlnIGluZGV4DQo+ID4gN2E5ZmI5Yi4uNjUxNzQxMiAxMDA2NDQNCj4gPiAtLS0g
YS9kcml2ZXJzL3NvYy9mc2wvS2NvbmZpZw0KPiA+ICsrKyBiL2RyaXZlcnMvc29jL2ZzbC9LY29u
ZmlnDQo+ID4gQEAgLTE2LDMgKzE2LDE3IEBAIGNvbmZpZyBGU0xfR1VUUw0KPiA+ICAJICBJbml0
aWFsbHkgb25seSByZWFkaW5nIFNWUiBhbmQgcmVnaXN0ZXJpbmcgc29jIGRldmljZSBhcmUNCj4g
PiBzdXBwb3J0ZWQuDQo+ID4gIAkgIE90aGVyIGd1dHMgYWNjZXNzZXMsIHN1Y2ggYXMgcmVhZGlu
ZyBSQ1csIHNob3VsZCBldmVudHVhbGx5IGJlDQo+ID4gbW92ZWQNCj4gPiAgCSAgaW50byB0aGlz
IGRyaXZlciBhcyB3ZWxsLg0KPiArDQo+ID4gK2NvbmZpZyBGU0xfUExBVF9QTQ0KPiA+ICsJYm9v
bCAiRnJlZXNjYWxlIHBsYXRmb3JtIFBNIGZyYW1ld29yayINCj4gDQo+IFRoaXMgbmFtZSBzZWVt
cyB0byBiZSBzaW11bHRhbmVvdXNseSB0b28gZ2VuZXJpYyAoZm9yIHNvbWV0aGluZyB0aGF0IGlz
DQo+IGxpa2VseSBpbnRlbmRlZCBvbmx5IGZvciB1c2Ugd2l0aCBjZXJ0YWluIEZyZWVzY2FsZS9O
WFAgY2hpcCBmYW1pbGllcykgYW5kIHRvbw0KPiBzcGVjaWZpYyAoZm9yIHNvbWV0aGluZyB0aGF0
IHNlZW1zIHRvIGJlIGdlbmVyYWwgaW5mcmFzdHJ1Y3R1cmUgd2l0aCBubyByZWFsDQo+IGhhcmR3
YXJlIGRlcGVuZGVuY2llcykuDQoNClllcywgdGhpcyBkcml2ZXIgaGFzIG5vIHJlYWwgSFcgZGVw
ZW5kZW5jaWVzIGF0IGFsbC4gQnV0IHdlJ2QgbGlrZSB0byBpbnRyb2R1Y2UgaXQNCnRvIGhlbHAg
cHJvdmlkaW5nIG1vcmUgZmxleGliaWxpdHkgJiBnZW5lcmljIG9uIEZTTCBQTSBmZWF0dXJlIGNv
bmZpZ3VyZSAoc28gZmFyIA0Kd2UgaGF2ZSBSQ1BNIG9uIHN5c3RlbSB3YWtldXAgc291cmNlIGNv
bnRyb2wpLiBJIHRoaW5rIGl0J3MgZ29vZA0KZm9yIGRyaXZlci9JUCBwb3J0aW5nIGFtb25nIGRp
ZmZlcmVudCBTb0MgaW4gdGhlIGZ1dHVyZS4gQXMgdG8gdGhlIG5hbWUsIGRvIHlvdQ0KaGF2ZSBi
ZXR0ZXIgc3VnZ2VzdGlvbj8NCg0KPiBXaGF0IHNwZWNpZmljIHByb2JsZW1zIHdpdGggTGludXgn
cyBnZW5lcmljIHdha2V1cCBpbmZyYXN0cnVjdHVyZSBpcyB0aGlzDQo+IHRyeWluZyB0byBzb2x2
ZSwgYW5kIHdoeSB3b3VsZCB0aG9zZSBwcm9ibGVtcyBub3QgYmUgYmV0dGVyIHNvbHZlZCB0aGVy
ZT8NCg0KQWN0dWFsbHksIEkgYW0gbm90IHN1cmUgaWYgZ2VuZXJpYyB3YWtldXAgaW5mcmFzdHJ1
Y3R1cmUgaGF2ZSB0aGlzIGtpbmQgb2YgUE0gZmVhdHVyZQ0KKGtlZXAgc3BlY2lmaWMgSVAgYWxp
dmUgZHVyaW5nIHN5c3RlbSBzdXNwZW5kLCBjb3VsZCB5b3UgcGxlYXNlIHNob3cgbWU/KS4NCkFu
ZCBJIHRoaW5rIGl0IGlzIG5vdCBjb21tb24gcmVxdWlyZW1lbnQsIHNvIEkgZGVjaWRlIHRvIHB1
dCBpdCBpbiBGU0wgZm9sZGVyLiANCg0KPiBBbHNvLCB5b3Ugc2hvdWxkIENDIGxpbnV4LXBtIG9u
IHRoZXNlIHBhdGNoZXMuDQoNClllcywgdGhhbmtzIGZvciBzdWdnZXN0aW9uDQoNClJlZ2FyZHMs
DQpSYW4NCg0KPiAtU2NvdHQNCg0K
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid code patching freed init sections
From: Michal Suchánek @ 2018-09-10 9:54 UTC (permalink / raw)
To: Michael Neuling; +Cc: mpe, linuxppc-dev, Haren Myneni, Nicholas Piggin
In-Reply-To: <20180910054405.32422-1-mikey@neuling.org>
On Mon, 10 Sep 2018 15:44:05 +1000
Michael Neuling <mikey@neuling.org> wrote:
> This stops us from doing code patching in init sections after they've
> been freed.
>
> In this chain:
> kvm_guest_init() ->
> kvm_use_magic_page() ->
> fault_in_pages_readable() ->
> __get_user() ->
> __get_user_nocheck() ->
> barrier_nospec();
>
> We have a code patching location at barrier_nospec() and
> kvm_guest_init() is an init function. This whole chain gets inlined,
> so when we free the init section (hence kvm_guest_init()), this code
> goes away and hence should no longer be patched.
>
> We seen this as userspace memory corruption when using a memory
> checker while doing partition migration testing on powervm (this
> starts the code patching post migration via
> /sys/kernel/mobility/migration). In theory, it could also happen when
> using /sys/kernel/debug/powerpc/barrier_nospec.
>
> With this patch there is a small change of a race if we code patch
> between the init section being freed and setting SYSTEM_RUNNING (in
> kernel_init()) but that seems like an impractical time and small
> window for any code patching to occur.
>
> cc: stable@vger.kernel.org # 4.13+
> Signed-off-by: Michael Neuling <mikey@neuling.org>
>
> ---
> For stable I've marked this as v4.13+ since that's when we refactored
> code-patching.c but it could go back even further than that. In
> reality though, I think we can only hit this since the first
> spectre/meltdown changes.
> ---
> arch/powerpc/lib/code-patching.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/powerpc/lib/code-patching.c
> b/arch/powerpc/lib/code-patching.c index 850f3b8f4d..a2bc08bfd8 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -23,11 +23,30 @@
> #include <asm/code-patching.h>
> #include <asm/setup.h>
>
> +
> +static inline bool in_init_section(unsigned int *patch_addr)
> +{
> + if (patch_addr < (unsigned int *)__init_begin)
> + return false;
> + if (patch_addr >= (unsigned int *)__init_end)
> + return false;
> + return true;
> +}
> +
> +static inline bool init_freed(void)
> +{
> + return (system_state >= SYSTEM_RUNNING);
> +}
> +
> static int __patch_instruction(unsigned int *exec_addr, unsigned int
> instr, unsigned int *patch_addr)
> {
> int err;
>
> + /* Make sure we aren't patching a freed init section */
> + if (in_init_section(patch_addr) && init_freed())
> + return 0;
> +
Do we even need the init_freed() check?
What user input can we process in init-only code?
Also it would be nice to write the function+offset of the skipped patch
location into the kernel log.
Thanks
Michal
^ permalink raw reply
* Re: Conflict between sparse and commit cafa0010cd51f ("Raise the minimum required gcc version to 4.6")
From: Christophe Leroy @ 2018-09-10 9:56 UTC (permalink / raw)
To: Luc Van Oostenryck
Cc: Nick Desaulniers, joe, Kees Cook, LKML, linux-sparse, sparse,
linuxppc-dev
In-Reply-To: <20180910092835.v5nex5nzfgtl475m@ltop.local>
On 09/10/2018 09:28 AM, Luc Van Oostenryck wrote:
> On Mon, Sep 10, 2018 at 08:49:07AM +0200, Christophe LEROY wrote:
>> Le 07/09/2018 à 20:19, Nick Desaulniers a écrit :
>>> On Fri, Sep 7, 2018 at 11:13 AM Luc Van Oostenryck wrote:
>>>>
>>>> Sparse expand these macros to the same version than the compiler used
>>>> to compile GCC. I find a bit strange though to have sparse v0.5.2 but
>>>> using an old compiler.
>>>
>>> So Christophe must have a version of gcc < 4.6 installed somewhere?
>>> Does sparse use `cc`? If so, Christophe, does your `ls -l $(which cc)`
>>> point to an old version of gcc maybe?
>>
>> Indeed it looks like sparse expand these macros to the version of
>> the compiler it was compiled with.
>>
>> I'm building kernels for a powerpc platforms, with CROSS_COMPILE set
>> to ppc-linux- and ppc-linux-gcc being version 5.4
>>
>> However my build machine is a CentOS6 and the native gcc has version
>> 4.4.7, so sparse expands that version.
>
> OK, I see.
>
>> Is there a way to get sparse in line with my cross compiler version
>> and not with the local native version ?
>
> When cross-compiling, there is also things like the machine word-size
> and the endianness to take in account (they also default to the
> native compiler used to compile sparse itself) as well as a few
> defines (like __PPC64__). To be in line with your cross-compiler
> you can use to the wrapper 'cgcc' (installed with sparse) and call
> it, for example, like this:
> $ export REAL_CC=ppc-linux-gcc
> $ cgcc -target=ppcc64 -D_CALL_ELF=2 -D__GCC__=5 -D__GCC_MINOR__=4 ...
> or, since this is for the kernel:
> $ export REAL_CC=ppc-linux-gcc
> $ make CHECK='cgcc -target=ppcc64 ...
>
>
> I think this should solve it. Do not hesitate to report any
> difficulties you may encounter.
# export REAL_CC=ppc-linux-gcc
# make CHECK="cgcc -target=ppc -D_CALL_ELF=2 -D__GCC__=5
-D__GCC_MINOR__=4" C=2 arch/powerpc/kernel/process.o
scripts/kconfig/conf --syncconfig Kconfig
#
# configuration written to .config
#
UPD include/config/kernel.release
UPD include/generated/utsrelease.h
CC kernel/bounds.s
CC arch/powerpc/kernel/asm-offsets.s
CALL scripts/checksyscalls.sh
CHECK scripts/mod/empty.c
Can't exec "/bin/sh": Argument list too long at /usr/local/bin/cgcc line 86.
make[2]: *** [scripts/mod/empty.o] Error 1
make[1]: *** [scripts/mod] Error 2
make: *** [scripts] Error 2
Christophe
>
> -- Luc
>
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid code patching freed init sections
From: Michael Neuling @ 2018-09-10 10:01 UTC (permalink / raw)
To: Michal Suchánek; +Cc: mpe, linuxppc-dev, Haren Myneni, Nicholas Piggin
In-Reply-To: <20180910101001.71a31102@naga.suse.cz>
> > For stable I've marked this as v4.13+ since that's when we refactored
> > code-patching.c but it could go back even further than that. In
> > reality though, I think we can only hit this since the first
> > spectre/meltdown changes.
>=20
> Which means it affects all maintained stable trees because the
> spectre/meltdown changes are backported.
Yep we this this on SLES12 SP3=20
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid code patching freed init sections
From: Michael Neuling @ 2018-09-10 10:05 UTC (permalink / raw)
To: Michal Suchánek
Cc: mpe, linuxppc-dev, Haren Myneni, Nicholas Piggin, Paul Mackerras
In-Reply-To: <20180910115457.60366160@naga.suse.cz>
> > + /* Make sure we aren't patching a freed init section */
> > + if (in_init_section(patch_addr) && init_freed())
> > + return 0;
> > +
>=20
> Do we even need the init_freed() check?
Maybe not. If userspace isn't up, then maybe it's ok to skip.
> What user input can we process in init-only code?
See the stack trace in the commit message. It's a weird case for KVM guests=
in
KVM PR mode.=20
That's the only case I can found so far.
> Also it would be nice to write the function+offset of the skipped patch
> location into the kernel log.
OK. I'll update.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid code patching freed init sections
From: Christophe LEROY @ 2018-09-10 10:16 UTC (permalink / raw)
To: Michael Neuling, Michal Suchánek
Cc: linuxppc-dev, Nicholas Piggin, Haren Myneni
In-Reply-To: <794308ed6aa6dcccf96e10bb0e3fa8d2dab9adff.camel@neuling.org>
Le 10/09/2018 à 12:05, Michael Neuling a écrit :
>
>>> + /* Make sure we aren't patching a freed init section */
>>> + if (in_init_section(patch_addr) && init_freed())
>>> + return 0;
>>> +
>>
>> Do we even need the init_freed() check?
>
> Maybe not. If userspace isn't up, then maybe it's ok to skip.
Euh ... Do you mean you'll skip all patches into init functions ?
But code patching is not only for meltdown/spectrum workarounds, some of
the patchings might be needed for the init functions themselves.
Christophe
>
>> What user input can we process in init-only code?
>
> See the stack trace in the commit message. It's a weird case for KVM guests in
> KVM PR mode.
>
> That's the only case I can found so far.
>
>> Also it would be nice to write the function+offset of the skipped patch
>> location into the kernel log.
>
> OK. I'll update.
>
> Mikey
>
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid code patching freed init sections
From: Michal Suchánek @ 2018-09-10 10:44 UTC (permalink / raw)
To: Christophe LEROY
Cc: Michael Neuling, linuxppc-dev, Haren Myneni, Nicholas Piggin
In-Reply-To: <3023d79c-cc38-037a-3617-832fed397a3d@c-s.fr>
On Mon, 10 Sep 2018 12:16:35 +0200
Christophe LEROY <christophe.leroy@c-s.fr> wrote:
> Le 10/09/2018 =C3=A0 12:05, Michael Neuling a =C3=A9crit=C2=A0:
> > =20
> >>> + /* Make sure we aren't patching a freed init section */
> >>> + if (in_init_section(patch_addr) && init_freed())
> >>> + return 0;
> >>> + =20
> >>
> >> Do we even need the init_freed() check? =20
> >=20
> > Maybe not. If userspace isn't up, then maybe it's ok to skip. =20
>=20
> Euh ... Do you mean you'll skip all patches into init functions ?
> But code patching is not only for meltdown/spectrum workarounds, some
> of the patchings might be needed for the init functions themselves.
Some stuff like cpu feature tests have an early variant that does not
need patching but maybe not everything has.
and some stuff like lwsync might be also expanded from some macros or
inlines and may be needed in the init code. It might be questionable to
rely on it getting patched, though. Hard to tell without seeing what is
actually patched where.
Thanks
Michal
^ permalink raw reply
* [tip:sched/core] sched/topology: Set correct NUMA topology type
From: tip-bot for Srikar Dronamraju @ 2018-09-10 10:06 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, linuxppc-dev, torvalds, wild, suravee.suthikulpanit,
hpa, mingo, mpe, heiko.carstens, tglx, peterz, riel, srikar,
mgorman
In-Reply-To: <1533920419-17410-1-git-send-email-srikar@linux.vnet.ibm.com>
Commit-ID: e5e96fafd9028b1478b165db78c52d981c14f471
Gitweb: https://git.kernel.org/tip/e5e96fafd9028b1478b165db78c52d981c14f471
Author: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
AuthorDate: Fri, 10 Aug 2018 22:30:18 +0530
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 10 Sep 2018 10:13:45 +0200
sched/topology: Set correct NUMA topology type
With the following commit:
051f3ca02e46 ("sched/topology: Introduce NUMA identity node sched domain")
the scheduler introduced a new NUMA level. However this leads to the NUMA topology
on 2 node systems to not be marked as NUMA_DIRECT anymore.
After this commit, it gets reported as NUMA_BACKPLANE, because
sched_domains_numa_level is now 2 on 2 node systems.
Fix this by allowing setting systems that have up to 2 NUMA levels as
NUMA_DIRECT.
While here remove code that assumes that level can be 0.
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andre Wild <wild@linux.vnet.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Fixes: 051f3ca02e46 "Introduce NUMA identity node sched domain"
Link: http://lkml.kernel.org/r/1533920419-17410-1-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
kernel/sched/topology.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 56a0fed30c0a..505a41c42b96 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1295,7 +1295,7 @@ static void init_numa_topology_type(void)
n = sched_max_numa_distance;
- if (sched_domains_numa_levels <= 1) {
+ if (sched_domains_numa_levels <= 2) {
sched_numa_topology_type = NUMA_DIRECT;
return;
}
@@ -1380,9 +1380,6 @@ void sched_init_numa(void)
break;
}
- if (!level)
- return;
-
/*
* 'level' contains the number of unique distances
*
^ permalink raw reply related
* Re: Conflict between sparse and commit cafa0010cd51f ("Raise the minimum required gcc version to 4.6")
From: Luc Van Oostenryck @ 2018-09-10 11:34 UTC (permalink / raw)
To: Christophe Leroy
Cc: Nick Desaulniers, joe, Kees Cook, LKML, linux-sparse, sparse,
linuxppc-dev
In-Reply-To: <061b3056-1a9a-af6b-de2a-49fea394320d@c-s.fr>
On Mon, Sep 10, 2018 at 09:56:33AM +0000, Christophe Leroy wrote:
>
> # export REAL_CC=ppc-linux-gcc
> # make CHECK="cgcc -target=ppc -D_CALL_ELF=2 -D__GCC__=5
> -D__GCC_MINOR__=4" C=2 arch/powerpc/kernel/process.o
> scripts/kconfig/conf --syncconfig Kconfig
> #
> # configuration written to .config
> #
> UPD include/config/kernel.release
> UPD include/generated/utsrelease.h
> CC kernel/bounds.s
> CC arch/powerpc/kernel/asm-offsets.s
> CALL scripts/checksyscalls.sh
> CHECK scripts/mod/empty.c
> Can't exec "/bin/sh": Argument list too long at /usr/local/bin/cgcc line 86.
> make[2]: *** [scripts/mod/empty.o] Error 1
> make[1]: *** [scripts/mod] Error 2
> make: *** [scripts] Error 2
OK. Clearly nobody has ever used it so :(
There is an infinite loop because cgcc use the env var CHECK
to call sparse while kbuild use CHECK to call cgcc here.
The following seems to work here.
$ export REAL_CC=ppc-linux-gcc
$ make CHECK="CHECK=sparse cgcc -target=ppc ...
It's a bit kludgy, I admit.
-- Luc
^ permalink raw reply
* 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()
From: Rob Herring @ 2018-09-10 12:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Finn Thain, Stan Johnson
Cc: Frank Rowand, Chintan Pandya, devicetree, linux-kernel,
linuxppc-dev
In-Reply-To: <7427daf6570d519e6793eb96d2fbaa52714b0cd7.camel@kernel.crashing.org>
On Sun, Sep 09, 2018 at 07:04:25PM +0200, Benjamin Herrenschmidt wrote:
> On Fri, 2018-08-31 at 14:58 +1000, Benjamin Herrenschmidt wrote:
> >
> > > A long shot, but something to consider, is that I failed to cover the
> > > cases of dynamic devicetree updates (removing nodes that contain a
> > > phandle) in ways other than overlays. Michael Ellerman has reported
> > > such a problem for powerpc/mobility with of_detach_node(). A patch to
> > > fix that is one of the tasks I need to complete.
> >
> > The only thing I can think of is booting via the BootX bootloader on
> > those ancient macs results in a DT with no phandles. I didn't see an
> > obvious reason why that would cause that patch to break though.
>
> Guys, we still don't have a fix for this one on its way upstream...
>
> My test patch just creates phandle properties for all nodes, that was
> not intended as a fix, more a way to check if the problem was related
> to the lack of phandles.
>
> I don't actually know why the new code causes things to fail when
> phandles are absent. This needs to be looked at.
>
> I'm travelling at the moment and generally caught up with other things,
> I haven't had a chance to dig, so just a heads up. I don't intend to
> submit my patch since it's just a band aid. We need to figure out what
> the actual problem is.
Can you try this patch (w/o Ben's patch). I think the problem is if
there are no phandles, then roundup_pow_of_two is passed 0 which is
documented as undefined result.
Though, if a DT has no properties with phandles, then why are we doing a
lookup in the first place?
8<----------------------------------------------------------------------
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 9095b8290150..74eaedd5b860 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -140,6 +140,9 @@ void of_populate_phandle_cache(void)
if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL)
phandles++;
+ if (!phandles)
+ goto out;
+
cache_entries = roundup_pow_of_two(phandles);
phandle_cache_mask = cache_entries - 1;
^ permalink raw reply related
* Re: Conflict between sparse and commit cafa0010cd51f ("Raise the minimum required gcc version to 4.6")
From: Christophe Leroy @ 2018-09-10 13:19 UTC (permalink / raw)
To: Luc Van Oostenryck
Cc: Nick Desaulniers, joe, Kees Cook, LKML, linux-sparse, sparse,
linuxppc-dev
In-Reply-To: <20180910113448.dxnfvznyimtj3tkv@ltop.local>
On 09/10/2018 11:34 AM, Luc Van Oostenryck wrote:
> On Mon, Sep 10, 2018 at 09:56:33AM +0000, Christophe Leroy wrote:
>>
>> # export REAL_CC=ppc-linux-gcc
>> # make CHECK="cgcc -target=ppc -D_CALL_ELF=2 -D__GCC__=5
>> -D__GCC_MINOR__=4" C=2 arch/powerpc/kernel/process.o
>> scripts/kconfig/conf --syncconfig Kconfig
>> #
>> # configuration written to .config
>> #
>> UPD include/config/kernel.release
>> UPD include/generated/utsrelease.h
>> CC kernel/bounds.s
>> CC arch/powerpc/kernel/asm-offsets.s
>> CALL scripts/checksyscalls.sh
>> CHECK scripts/mod/empty.c
>> Can't exec "/bin/sh": Argument list too long at /usr/local/bin/cgcc line 86.
>> make[2]: *** [scripts/mod/empty.o] Error 1
>> make[1]: *** [scripts/mod] Error 2
>> make: *** [scripts] Error 2
>
> OK. Clearly nobody has ever used it so :(
> There is an infinite loop because cgcc use the env var CHECK
> to call sparse while kbuild use CHECK to call cgcc here.
>
> The following seems to work here.
> $ export REAL_CC=ppc-linux-gcc
> $ make CHECK="CHECK=sparse cgcc -target=ppc ...
Not yet ...
[root@pc16082vm linux-powerpc]# export REAL_CC=ppc-linux-gcc
[root@pc16082vm linux-powerpc]# make CHECK="CHECK=sparse cgcc
-target=ppc -D_CALL_ELF=2 -D__GNUC__=5 -D__GNUC_MINOR__=4" C=2
arch/powerpc/kernel/process.o
CALL scripts/checksyscalls.sh
CHECK scripts/mod/empty.c
<command-line>:0:0: warning: "__STDC__" redefined
<built-in>: note: this is the location of the previous definition
/opt/cldk-1.4.0/lib/gcc/ppc-linux/5.4.0/../../../../ppc-linux/lib/crt1.o:(.rodata+0x4):
undefined reference to `main'
collect2: error: ld returned 1 exit status
make[2]: *** [scripts/mod/empty.o] Error 1
make[1]: *** [scripts/mod] Error 2
make: *** [scripts] Error 2
Christophe
>
> It's a bit kludgy, I admit.
>
> -- Luc
>
^ permalink raw reply
* Re: [PATCH v2 0/3] powerpc/pseries: use H_BLOCK_REMOVE
From: Laurent Dufour @ 2018-09-10 13:38 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, mpe; +Cc: aneesh.kumar, benh, paulus, npiggin
In-Reply-To: <1534775376-22480-1-git-send-email-ldufour@linux.vnet.ibm.com>
Hi Michael,
Do you plan to pull it for 4.20 ?
Cheers,
Laurent.
On 20/08/2018 16:29, Laurent Dufour wrote:
> On very large system we could see soft lockup fired when a process is
> exiting
>
> watchdog: BUG: soft lockup - CPU#851 stuck for 21s! [forkoff:215523]
> Modules linked in: pseries_rng rng_core xfs raid10 vmx_crypto btrfs libcrc32c xor zstd_decompress zstd_compress xxhash lzo_compress raid6_pq crc32c_vpmsum lpfc crc_t10dif crct10dif_generic crct10dif_common dm_multipath scsi_dh_rdac scsi_dh_alua autofs4
> CPU: 851 PID: 215523 Comm: forkoff Not tainted 4.17.0 #1
> NIP: c0000000000b995c LR: c0000000000b8f64 CTR: 000000000000aa18
> REGS: c00006b0645b7610 TRAP: 0901 Not tainted (4.17.0)
> MSR: 800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 22042082 XER: 00000000
> CFAR: 00000000006cf8f0 SOFTE: 0
> GPR00: 0010000000000000 c00006b0645b7890 c000000000f99200 0000000000000000
> GPR04: 8e000001a5a4de58 400249cf1bfd5480 8e000001a5a4de50 400249cf1bfd5480
> GPR08: 8e000001a5a4de48 400249cf1bfd5480 8e000001a5a4de40 400249cf1bfd5480
> GPR12: ffffffffffffffff c00000001e690800
> NIP [c0000000000b995c] plpar_hcall9+0x44/0x7c
> LR [c0000000000b8f64] pSeries_lpar_flush_hash_range+0x324/0x3d0
> Call Trace:
> [c00006b0645b7890] [8e000001a5a4dd20] 0x8e000001a5a4dd20 (unreliable)
> [c00006b0645b7a00] [c00000000006d5b0] flush_hash_range+0x60/0x110
> [c00006b0645b7a50] [c000000000072a2c] __flush_tlb_pending+0x4c/0xd0
> [c00006b0645b7a80] [c0000000002eaf44] unmap_page_range+0x984/0xbd0
> [c00006b0645b7bc0] [c0000000002eb594] unmap_vmas+0x84/0x100
> [c00006b0645b7c10] [c0000000002f8afc] exit_mmap+0xac/0x1f0
> [c00006b0645b7cd0] [c0000000000f2638] mmput+0x98/0x1b0
> [c00006b0645b7d00] [c0000000000fc9d0] do_exit+0x330/0xc00
> [c00006b0645b7dc0] [c0000000000fd384] do_group_exit+0x64/0x100
> [c00006b0645b7e00] [c0000000000fd44c] sys_exit_group+0x2c/0x30
> [c00006b0645b7e30] [c00000000000b960] system_call+0x58/0x6c
> Instruction dump:
> 60000000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378
> e9410060 e9610068 e9810070 44000022 <7d806378> e9810028 f88c0000 f8ac0008
>
> This happens when removing the PTE by calling the hypervisor using the
> H_BULK_REMOVE call. This call is processing up to 4 PTEs but is doing a
> tlbie for each PTE it is processing. This could lead to long time spent in
> the hypervisor (sometimes up to 4s) and soft lockup being raised because
> the scheduler is not called in zap_pte_range().
>
> Since the Power7's time, the hypervisor is providing a new hcall
> H_BLOCK_REMOVE allowing processing up to 8 PTEs with one call to
> tlbie. By limiting the amount of tlbie generated, this reduces the time
> spent invalidating the PTEs.
>
> This hcall requires that the pages are "all within the same naturally
> aligned 8 page virtual address block".
>
> With this patch series applied, I couldn't see any soft lockup raised on
> the victim LPAR I was running the test one.
>
> Changes since V1:
> - Remove a call to BUG_ON() in call_block_remove() since this one can be
> handled gently.
> - Remove uneeded of current_vpgb to 0 when retrying entries in
> hugepage_block_invalidate() and do_block_remove().
>
> Laurent Dufour (3):
> powerpc/pseries/mm: Introducing FW_FEATURE_BLOCK_REMOVE
> powerpc/pseries/mm: factorize PTE slot computation
> powerpc/pseries/mm: call H_BLOCK_REMOVE
>
> arch/powerpc/include/asm/firmware.h | 3 +-
> arch/powerpc/include/asm/hvcall.h | 1 +
> arch/powerpc/platforms/pseries/firmware.c | 1 +
> arch/powerpc/platforms/pseries/lpar.c | 241 ++++++++++++++++++++++++++++--
> 4 files changed, 230 insertions(+), 16 deletions(-)
>
^ permalink raw reply
* [PATCH 0/7 v7] Support for fsl-mc bus and its devices in SMMU
From: Nipun Gupta @ 2018-09-10 13:49 UTC (permalink / raw)
To: joro, robin.murphy, will.deacon, robh+dt, robh, mark.rutland,
catalin.marinas, gregkh, laurentiu.tudor, bhelgaas, hch
Cc: m.szyprowski, shawnguo, frowand.list, iommu, linux-kernel,
devicetree, linux-arm-kernel, linuxppc-dev, linux-pci,
bharat.bhushan, stuyoder, leoyang.li, Nipun Gupta
This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.
These patches
- Define property 'iommu-map' for fsl-mc bus (patch 1)
- Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3,4)
- Adds the dma configuration support for fsl-mc bus (patch 5, 6)
- Updates the fsl-mc device node with iommu/dma related changes (patch 7)
Changes in v2:
- use iommu-map property for fsl-mc bus
- rebase over patchset https://patchwork.kernel.org/patch/10317337/
and make corresponding changes for dma configuration of devices on
fsl-mc bus
Changes in v3:
- move of_map_rid in drivers/of/address.c
Changes in v4:
- move of_map_rid in drivers/of/base.c
Changes in v5:
- break patch 5 in two separate patches (now patch 5/7 and patch 6/7)
- add changelog text in patch 3/7 and patch 5/7
- typo fix
Changes in v6:
- Updated fsl_mc_device_group() API to be more rational
- Added dma-coherent property in the LS2 smmu device node
- Minor fixes in the device-tree documentation
Changes in v7:
- Rebased over linux 4.19
Nipun Gupta (7):
Documentation: fsl-mc: add iommu-map device-tree binding for fsl-mc
bus
iommu/of: make of_pci_map_rid() available for other devices too
iommu/of: support iommu configuration for fsl-mc devices
iommu/arm-smmu: Add support for the fsl-mc bus
bus: fsl-mc: support dma configure for devices on fsl-mc bus
bus: fsl-mc: set coherent dma mask for devices on fsl-mc bus
arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 7 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 16 +++-
drivers/iommu/arm-smmu.c | 7 ++
drivers/iommu/iommu.c | 13 +++
drivers/iommu/of_iommu.c | 25 ++++-
drivers/of/base.c | 102 +++++++++++++++++++++
drivers/of/irq.c | 5 +-
drivers/pci/of.c | 101 --------------------
include/linux/fsl/mc.h | 8 ++
include/linux/iommu.h | 2 +
include/linux/of.h | 11 +++
include/linux/of_pci.h | 10 --
13 files changed, 224 insertions(+), 122 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/7 v7] Documentation: fsl-mc: add iommu-map device-tree binding for fsl-mc bus
From: Nipun Gupta @ 2018-09-10 13:49 UTC (permalink / raw)
To: joro, robin.murphy, will.deacon, robh+dt, robh, mark.rutland,
catalin.marinas, gregkh, laurentiu.tudor, bhelgaas, hch
Cc: m.szyprowski, shawnguo, frowand.list, iommu, linux-kernel,
devicetree, linux-arm-kernel, linuxppc-dev, linux-pci,
bharat.bhushan, stuyoder, leoyang.li, Nipun Gupta
In-Reply-To: <1536587361-11047-1-git-send-email-nipun.gupta@nxp.com>
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
---
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..01fdc33 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices
such as network interfaces, crypto accelerator instances, L2 switches,
etc.
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+Documentation/networking/dpaa2/overview.rst
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
Required properties:
- compatible
@@ -88,14 +107,34 @@ Sub-nodes:
Value type: <phandle>
Definition: Specifies the phandle to the PHY device node associated
with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+ data.
+
+ The property is an arbitrary number of tuples of
+ (icid-base,iommu,iommu-base,length).
+
+ Any ICID i in the interval [icid-base, icid-base + length) is
+ associated with the listed IOMMU, with the iommu-specifier
+ (i - icid-base + iommu-base).
Example:
+ smmu: iommu@5000000 {
+ compatible = "arm,mmu-500";
+ #iommu-cells = <1>;
+ stream-match-mask = <0x7C00>;
+ ...
+ };
+
fsl_mc: fsl-mc@80c000000 {
compatible = "fsl,qoriq-mc";
reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
<0x00000000 0x08340000 0 0x40000>; /* MC control reg */
msi-parent = <&its>;
+ /* define map for ICIDs 23-64 */
+ iommu-map = <23 &smmu 23 41>;
#address-cells = <3>;
#size-cells = <1>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/7 v7] iommu/of: make of_pci_map_rid() available for other devices too
From: Nipun Gupta @ 2018-09-10 13:49 UTC (permalink / raw)
To: joro, robin.murphy, will.deacon, robh+dt, robh, mark.rutland,
catalin.marinas, gregkh, laurentiu.tudor, bhelgaas, hch
Cc: m.szyprowski, shawnguo, frowand.list, iommu, linux-kernel,
devicetree, linux-arm-kernel, linuxppc-dev, linux-pci,
bharat.bhushan, stuyoder, leoyang.li, Nipun Gupta
In-Reply-To: <1536587361-11047-1-git-send-email-nipun.gupta@nxp.com>
iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.
'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/iommu/of_iommu.c | 5 +--
drivers/of/base.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/of/irq.c | 5 +--
drivers/pci/of.c | 101 ----------------------------------------------
include/linux/of.h | 11 +++++
include/linux/of_pci.h | 10 -----
6 files changed, 117 insertions(+), 117 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..811e160 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -149,9 +149,8 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
- err = of_pci_map_rid(info->np, alias, "iommu-map",
- "iommu-map-mask", &iommu_spec.np,
- iommu_spec.args);
+ err = of_map_rid(info->np, alias, "iommu-map", "iommu-map-mask",
+ &iommu_spec.np, iommu_spec.args);
if (err)
return err == -ENODEV ? NO_IOMMU : err;
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 848f549..c7aac81 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1995,3 +1995,105 @@ int of_find_last_cache_level(unsigned int cpu)
return cache_level;
}
+
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+ const char *map_name, const char *map_mask_name,
+ struct device_node **target, u32 *id_out)
+{
+ u32 map_mask, masked_rid;
+ int map_len;
+ const __be32 *map = NULL;
+
+ if (!np || !map_name || (!target && !id_out))
+ return -EINVAL;
+
+ map = of_get_property(np, map_name, &map_len);
+ if (!map) {
+ if (target)
+ return -ENODEV;
+ /* Otherwise, no map implies no translation */
+ *id_out = rid;
+ return 0;
+ }
+
+ if (!map_len || map_len % (4 * sizeof(*map))) {
+ pr_err("%pOF: Error: Bad %s length: %d\n", np,
+ map_name, map_len);
+ return -EINVAL;
+ }
+
+ /* The default is to select all bits. */
+ map_mask = 0xffffffff;
+
+ /*
+ * Can be overridden by "{iommu,msi}-map-mask" property.
+ * If of_property_read_u32() fails, the default is used.
+ */
+ if (map_mask_name)
+ of_property_read_u32(np, map_mask_name, &map_mask);
+
+ masked_rid = map_mask & rid;
+ for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+ struct device_node *phandle_node;
+ u32 rid_base = be32_to_cpup(map + 0);
+ u32 phandle = be32_to_cpup(map + 1);
+ u32 out_base = be32_to_cpup(map + 2);
+ u32 rid_len = be32_to_cpup(map + 3);
+
+ if (rid_base & ~map_mask) {
+ pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
+ np, map_name, map_name,
+ map_mask, rid_base);
+ return -EFAULT;
+ }
+
+ if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+ continue;
+
+ phandle_node = of_find_node_by_phandle(phandle);
+ if (!phandle_node)
+ return -ENODEV;
+
+ if (target) {
+ if (*target)
+ of_node_put(phandle_node);
+ else
+ *target = phandle_node;
+
+ if (*target != phandle_node)
+ continue;
+ }
+
+ if (id_out)
+ *id_out = masked_rid - rid_base + out_base;
+
+ pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
+ np, map_name, map_mask, rid_base, out_base,
+ rid_len, rid, masked_rid - rid_base + out_base);
+ return 0;
+ }
+
+ pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
+ np, map_name, rid, target && *target ? *target : NULL);
+ return -EFAULT;
+}
+EXPORT_SYMBOL_GPL(of_map_rid);
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 02ad93a..e1f6f39 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -22,7 +22,6 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_irq.h>
-#include <linux/of_pci.h>
#include <linux/string.h>
#include <linux/slab.h>
@@ -588,8 +587,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
* "msi-map" property.
*/
for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
- if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
- "msi-map-mask", np, &rid_out))
+ if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
+ "msi-map-mask", np, &rid_out))
break;
return rid_out;
}
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index d088c91..91600e0 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -357,107 +357,6 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev,
EXPORT_SYMBOL_GPL(devm_of_pci_get_host_bridge_resources);
#endif /* CONFIG_OF_ADDRESS */
-/**
- * of_pci_map_rid - Translate a requester ID through a downstream mapping.
- * @np: root complex device node.
- * @rid: PCI requester ID to map.
- * @map_name: property name of the map to use.
- * @map_mask_name: optional property name of the mask to use.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
- *
- * Given a PCI requester ID, look up the appropriate implementation-defined
- * platform ID and/or the target device which receives transactions on that
- * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
- * @id_out may be NULL if only the other is required. If @target points to
- * a non-NULL device node pointer, only entries targeting that node will be
- * matched; if it points to a NULL value, it will receive the device node of
- * the first matching target phandle, with a reference held.
- *
- * Return: 0 on success or a standard error code on failure.
- */
-int of_pci_map_rid(struct device_node *np, u32 rid,
- const char *map_name, const char *map_mask_name,
- struct device_node **target, u32 *id_out)
-{
- u32 map_mask, masked_rid;
- int map_len;
- const __be32 *map = NULL;
-
- if (!np || !map_name || (!target && !id_out))
- return -EINVAL;
-
- map = of_get_property(np, map_name, &map_len);
- if (!map) {
- if (target)
- return -ENODEV;
- /* Otherwise, no map implies no translation */
- *id_out = rid;
- return 0;
- }
-
- if (!map_len || map_len % (4 * sizeof(*map))) {
- pr_err("%pOF: Error: Bad %s length: %d\n", np,
- map_name, map_len);
- return -EINVAL;
- }
-
- /* The default is to select all bits. */
- map_mask = 0xffffffff;
-
- /*
- * Can be overridden by "{iommu,msi}-map-mask" property.
- * If of_property_read_u32() fails, the default is used.
- */
- if (map_mask_name)
- of_property_read_u32(np, map_mask_name, &map_mask);
-
- masked_rid = map_mask & rid;
- for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
- struct device_node *phandle_node;
- u32 rid_base = be32_to_cpup(map + 0);
- u32 phandle = be32_to_cpup(map + 1);
- u32 out_base = be32_to_cpup(map + 2);
- u32 rid_len = be32_to_cpup(map + 3);
-
- if (rid_base & ~map_mask) {
- pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
- np, map_name, map_name,
- map_mask, rid_base);
- return -EFAULT;
- }
-
- if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
- continue;
-
- phandle_node = of_find_node_by_phandle(phandle);
- if (!phandle_node)
- return -ENODEV;
-
- if (target) {
- if (*target)
- of_node_put(phandle_node);
- else
- *target = phandle_node;
-
- if (*target != phandle_node)
- continue;
- }
-
- if (id_out)
- *id_out = masked_rid - rid_base + out_base;
-
- pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
- np, map_name, map_mask, rid_base, out_base,
- rid_len, rid, masked_rid - rid_base + out_base);
- return 0;
- }
-
- pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
- np, map_name, rid, target && *target ? *target : NULL);
- return -EFAULT;
-}
-
#if IS_ENABLED(CONFIG_OF_IRQ)
/**
* of_irq_parse_pci - Resolve the interrupt for a PCI device
diff --git a/include/linux/of.h b/include/linux/of.h
index 4d25e4f..f4251c3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -545,6 +545,10 @@ const __be32 *of_prop_next_u32(struct property *prop, const __be32 *cur,
extern int of_cpu_node_to_id(struct device_node *np);
+int of_map_rid(struct device_node *np, u32 rid,
+ const char *map_name, const char *map_mask_name,
+ struct device_node **target, u32 *id_out);
+
#else /* CONFIG_OF */
static inline void of_core_init(void)
@@ -931,6 +935,13 @@ static inline int of_cpu_node_to_id(struct device_node *np)
return -ENODEV;
}
+static inline int of_map_rid(struct device_node *np, u32 rid,
+ const char *map_name, const char *map_mask_name,
+ struct device_node **target, u32 *id_out)
+{
+ return -EINVAL;
+}
+
#define of_match_ptr(_ptr) NULL
#define of_match_node(_matches, _node) NULL
#endif /* CONFIG_OF */
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index e83d87f..21a89c4 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -14,9 +14,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
int of_pci_get_devfn(struct device_node *np);
void of_pci_check_probe_only(void);
-int of_pci_map_rid(struct device_node *np, u32 rid,
- const char *map_name, const char *map_mask_name,
- struct device_node **target, u32 *id_out);
#else
static inline struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn)
@@ -29,13 +26,6 @@ static inline int of_pci_get_devfn(struct device_node *np)
return -EINVAL;
}
-static inline int of_pci_map_rid(struct device_node *np, u32 rid,
- const char *map_name, const char *map_mask_name,
- struct device_node **target, u32 *id_out)
-{
- return -EINVAL;
-}
-
static inline void of_pci_check_probe_only(void) { }
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH 3/7 v7] iommu/of: support iommu configuration for fsl-mc devices
From: Nipun Gupta @ 2018-09-10 13:49 UTC (permalink / raw)
To: joro, robin.murphy, will.deacon, robh+dt, robh, mark.rutland,
catalin.marinas, gregkh, laurentiu.tudor, bhelgaas, hch
Cc: m.szyprowski, shawnguo, frowand.list, iommu, linux-kernel,
devicetree, linux-arm-kernel, linuxppc-dev, linux-pci,
bharat.bhushan, stuyoder, leoyang.li, Nipun Gupta
In-Reply-To: <1536587361-11047-1-git-send-email-nipun.gupta@nxp.com>
With of_pci_map_rid available for all the busses, use the function
for configuration of devices on fsl-mc bus
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/of_iommu.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 811e160..284474d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
#include <linux/of_iommu.h>
#include <linux/of_pci.h>
#include <linux/slab.h>
+#include <linux/fsl/mc.h>
#define NO_IOMMU 1
@@ -159,6 +160,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
return err;
}
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+ struct device_node *master_np)
+{
+ struct of_phandle_args iommu_spec = { .args_count = 1 };
+ int err;
+
+ err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+ "iommu-map-mask", &iommu_spec.np,
+ iommu_spec.args);
+ if (err)
+ return err == -ENODEV ? NO_IOMMU : err;
+
+ err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+ of_node_put(iommu_spec.np);
+ return err;
+}
+
const struct iommu_ops *of_iommu_configure(struct device *dev,
struct device_node *master_np)
{
@@ -190,6 +208,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
err = pci_for_each_dma_alias(to_pci_dev(dev),
of_pci_iommu_init, &info);
+ } else if (dev_is_fsl_mc(dev)) {
+ err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
--
1.9.1
^ permalink raw reply related
* [PATCH 4/7 v7] iommu/arm-smmu: Add support for the fsl-mc bus
From: Nipun Gupta @ 2018-09-10 13:49 UTC (permalink / raw)
To: joro, robin.murphy, will.deacon, robh+dt, robh, mark.rutland,
catalin.marinas, gregkh, laurentiu.tudor, bhelgaas, hch
Cc: m.szyprowski, shawnguo, frowand.list, iommu, linux-kernel,
devicetree, linux-arm-kernel, linuxppc-dev, linux-pci,
bharat.bhushan, stuyoder, leoyang.li, Nipun Gupta
In-Reply-To: <1536587361-11047-1-git-send-email-nipun.gupta@nxp.com>
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 7 +++++++
drivers/iommu/iommu.c | 13 +++++++++++++
include/linux/fsl/mc.h | 8 ++++++++
include/linux/iommu.h | 2 ++
4 files changed, 30 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index f7a96bc..a011bb6 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
#include <linux/spinlock.h>
#include <linux/amba/bus.h>
+#include <linux/fsl/mc.h>
#include "io-pgtable.h"
#include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
if (dev_is_pci(dev))
group = pci_device_group(dev);
+ else if (dev_is_fsl_mc(dev))
+ group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
}
#endif
+#ifdef CONFIG_FSL_MC_BUS
+ if (!iommu_present(&fsl_mc_bus_type))
+ bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
}
static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d227b86..df2f49e 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
#include <linux/pci.h>
#include <linux/bitops.h>
#include <linux/property.h>
+#include <linux/fsl/mc.h>
#include <trace/events/iommu.h>
static struct kset *iommu_group_kset;
@@ -988,6 +989,18 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
}
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+ struct device *cont_dev = fsl_mc_cont_dev(dev);
+ struct iommu_group *group;
+
+ group = iommu_group_get(cont_dev);
+ if (!group)
+ group = iommu_group_alloc();
+ return group;
+}
+
/**
* iommu_group_get_for_dev - Find or create the IOMMU group for a device
* @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
#define dev_is_fsl_mc(_dev) (0)
#endif
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+ FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+ (_dev) : (_dev)->parent)
+
/*
* module_fsl_mc_driver() - Helper macro for drivers that don't do
* anything special in module init/exit. This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7447b0b..209891d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain,
extern struct iommu_group *pci_device_group(struct device *dev);
/* Generic device grouping function */
extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
/**
* struct iommu_fwspec - per-device IOMMU instance data
--
1.9.1
^ permalink raw reply related
* [PATCH 5/7 v7] bus/fsl-mc: support dma configure for devices on fsl-mc bus
From: Nipun Gupta @ 2018-09-10 13:49 UTC (permalink / raw)
To: joro, robin.murphy, will.deacon, robh+dt, robh, mark.rutland,
catalin.marinas, gregkh, laurentiu.tudor, bhelgaas, hch
Cc: m.szyprowski, shawnguo, frowand.list, iommu, linux-kernel,
devicetree, linux-arm-kernel, linuxppc-dev, linux-pci,
bharat.bhushan, stuyoder, leoyang.li, Nipun Gupta
In-Reply-To: <1536587361-11047-1-git-send-email-nipun.gupta@nxp.com>
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..fa43c7d 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
return 0;
}
+static int fsl_mc_dma_configure(struct device *dev)
+{
+ struct device *dma_dev = dev;
+
+ while (dev_is_fsl_mc(dma_dev))
+ dma_dev = dma_dev->parent;
+
+ return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+ .dma_configure = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
};
EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -633,10 +644,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
- /* Objects are coherent, unless 'no shareability' flag set. */
- if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
- arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
/*
* The device-specific probe callback will get invoked by device_add()
*/
--
1.9.1
^ permalink raw reply related
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