* RE: [PATCH 3/3] soc: fsl: add RCPM driver
From: Ran Wang @ 2018-09-07 9:48 UTC (permalink / raw)
To: Leo Li
Cc: dongsheng.wang@hxt-semitech.com, Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linuxppc-dev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CADRPPNQN=27+pOSckxvwSuBJoFaz7pT+Z6h07Wu3Liz5ao5kkA@mail.gmail.com>
SGkgTGVvLA0KDQpPbiBTZXB0ZW1iZXIgMDUsIDIwMTggYXQgMTE6MjIgWWFuZyBMaSB3cm90ZToN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGkgWWFuZyA8bGVveWFuZy5s
aUBueHAuY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNSwgMjAxOCAxMToyMg0K
PiBUbzogZG9uZ3NoZW5nLndhbmdAaHh0LXNlbWl0ZWNoLmNvbQ0KPiBDYzogUmFuIFdhbmcgPHJh
bi53YW5nXzFAbnhwLmNvbT47IFJvYiBIZXJyaW5nIDxyb2JoK2R0QGtlcm5lbC5vcmc+Ow0KPiBN
YXJrIFJ1dGxhbmQgPG1hcmsucnV0bGFuZEBhcm0uY29tPjsgb3BlbiBsaXN0Ok9QRU4gRklSTVdB
UkUgQU5EDQo+IEZMQVRURU5FRCBERVZJQ0UgVFJFRSBCSU5ESU5HUyA8ZGV2aWNldHJlZUB2Z2Vy
Lmtlcm5lbC5vcmc+OyBsaW51eHBwYy0NCj4gZGV2IDxsaW51eHBwYy1kZXZAbGlzdHMub3psYWJz
Lm9yZz47IGxrbWwgPGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+Ow0KPiBtb2RlcmF0ZWQg
bGlzdDpBUk0vRlJFRVNDQUxFIElNWCAvIE1YQyBBUk0gQVJDSElURUNUVVJFIDxsaW51eC1hcm0t
DQo+IGtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnPg0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDMv
M10gc29jOiBmc2w6IGFkZCBSQ1BNIGRyaXZlcg0KPiANCj4gT24gVHVlLCBTZXAgNCwgMjAxOCBh
dCA5OjU4IFBNIFdhbmcsIERvbmdzaGVuZyA8ZG9uZ3NoZW5nLndhbmdAaHh0LQ0KPiBzZW1pdGVj
aC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gUGxlYXNlIGNoYW5nZSB5b3VyIGNvbW1lbnRzIHN0eWxl
Lg0KPiANCj4gQWx0aG91Z2ggdGhpcyBkb2Vzbid0IGdldCBpbnRvIHRoZSBMaW51eCBrZXJuZWwg
Y29kaW5nIHN0eWxlIGRvY3VtZW50YXRpb24NCj4geWV0LCBMaW51cyBzZWVtcyBjaGFuZ2VkIGhp
cyBtaW5kIHRvIHByZWZlciAvLyB0aGFuIC8qDQo+ICovIGNvbW1lbnQgc3R5bGUgbm93Lg0KPiBo
dHRwczovL2VtZWEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz
JTNBJTJGJTJGbGttbA0KPiAub3JnJTJGbGttbCUyRjIwMTclMkYxMSUyRjI1JTJGMTMzJmFtcDtk
YXRhPTAyJTdDMDElN0NyYW4ud2FuZ18NCj4gMSU0MG54cC5jb20lN0NjMGQ4OGU2NjkwMzg0ZTAy
Yjk1MTA4ZDYxMmRlYzIzNSU3QzY4NmVhMWQzYmMyYjRjDQo+IDZmYTkyY2Q5OWM1YzMwMTYzNSU3
QzAlN0MwJTdDNjM2NzE3MTQ1Mjg1MTI2MjAwJmFtcDtzZGF0YT1KSW9DWnANCj4gV2hSeVc3NkVx
Z1NmbGZUREExZjBnTVFHS2ElMkZjYnZTYzVDTyUyRnclM0QmYW1wO3Jlc2VydmVkPTANCj4gU28g
dGhlDQo+IC8vIHN0eWxlIHNob3VsZCBiZSBhY2NlcHRhYmxlIGZvciBub3cuDQo+IA0KPiA+DQo+
ID4gT24gMjAxOC84LzMxIDExOjU2LCBSYW4gV2FuZyB3cm90ZToNCj4gPiA+IFRoZSBOWFAncyBR
b3JJUSBQcm9jZXNzb3JzIGJhc2VkIG9uIEFSTSBDb3JlIGhhdmUgUkNQTSBtb2R1bGUgKFJ1bg0K
PiA+ID4gQ29udHJvbCBhbmQgUG93ZXIgTWFuYWdlbWVudCksIHdoaWNoIHBlcmZvcm1zIGFsbCBk
ZXZpY2UtbGV2ZWwgdGFza3MNCj4gPiA+IGFzc29jaWF0ZWQgd2l0aCBwb3dlciBtYW5hZ2VtZW50
IHN1Y2ggYXMgd2FrZXVwIHNvdXJjZSBjb250cm9sLg0KPiA+ID4NCj4gPiA+IFRoaXMgZHJpdmVy
IGRlcGVuZHMgb24gRlNMIHBsYXRmb3JtIFBNIGRyaXZlciBmcmFtZXdvcmsgd2hpY2ggaGVscA0K
PiA+ID4gdG8gaXNvbGF0ZSB1c2VyIGFuZCBQTSBzZXJ2aWNlIHByb3ZpZGVyIChzdWNoIGFzIFJD
UE0gZHJpdmVyKS4NCj4gPiA+DQo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBDaGVuaHVpIFpoYW8gPGNo
ZW5odWkuemhhb0BueHAuY29tPg0KPiA+ID4gU2lnbmVkLW9mZi1ieTogWWluZyBaaGFuZyA8eWlu
Zy56aGFuZzIyNDU1QG54cC5jb20+DQo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBSYW4gV2FuZyA8cmFu
LndhbmdfMUBueHAuY29tPg0KPiA+ID4gLS0tDQo+ID4gPiAgZHJpdmVycy9zb2MvZnNsL0tjb25m
aWcgICB8ICAgIDYgKysNCj4gPiA+ICBkcml2ZXJzL3NvYy9mc2wvTWFrZWZpbGUgIHwgICAgMSAr
DQo+ID4gPiAgZHJpdmVycy9zb2MvZnNsL2xzLXJjcG0uYyB8ICAxNTMNCj4gPiA+ICsrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPiA+ID4gIDMgZmlsZXMgY2hh
bmdlZCwgMTYwIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pICBjcmVhdGUgbW9kZQ0KPiA+
ID4gMTAwNjQ0IGRyaXZlcnMvc29jL2ZzbC9scy1yY3BtLmMNCj4gPiA+DQo+ID4gPiBkaWZmIC0t
Z2l0IGEvZHJpdmVycy9zb2MvZnNsL0tjb25maWcgYi9kcml2ZXJzL3NvYy9mc2wvS2NvbmZpZyBp
bmRleA0KPiA+ID4gNjUxNzQxMi4uODgyMzMwZCAxMDA2NDQNCj4gPiA+IC0tLSBhL2RyaXZlcnMv
c29jL2ZzbC9LY29uZmlnDQo+ID4gPiArKysgYi9kcml2ZXJzL3NvYy9mc2wvS2NvbmZpZw0KPiA+
ID4gQEAgLTMwLDMgKzMwLDkgQEAgY29uZmlnIEZTTF9QTEFUX1BNDQo+ID4gPiAgICAgICAgIGhh
dmUgdG8ga25vdyB0aGUgaW1wbGVtZW50IGRldGFpbHMgb2Ygd2FrZXVwIGZ1bmN0aW9uIGl0IHJl
cXVpcmUuDQo+ID4gPiAgICAgICAgIEJlc2lkZXMsIGl0IGlzIGFsc28gZWFzeSBmb3Igc2Vydmlj
ZSBzaWRlIHRvIHVwZ3JhZGUgaXRzIGxvZ2ljIHdoZW4NCj4gPiA+ICAgICAgICAgZGVzaWduIGNo
YW5nZWQgYW5kIHJlbWFpbiB1c2VyIHNpZGUgdW5jaGFuZ2VkLg0KPiA+ID4gKw0KPiA+ID4gK2Nv
bmZpZyBMU19SQ1BNDQo+ID4gPiArICAgICBib29sICJGcmVlc2NhbGUgUkNQTSBzdXBwb3J0Ig0K
PiA+ID4gKyAgICAgZGVwZW5kcyBvbiAoRlNMX1BMQVRfUE0pDQo+ID4gPiArICAgICBoZWxwDQo+
ID4gPiArICAgICAgIFRoaXMgZmVhdHVyZSBpcyB0byBlbmFibGUgc3BlY2lmaWVkIHdha2V1cCBz
b3VyY2UgZm9yIHN5c3RlbSBzbGVlcC4NCj4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3NvYy9m
c2wvTWFrZWZpbGUgYi9kcml2ZXJzL3NvYy9mc2wvTWFrZWZpbGUNCj4gPiA+IGluZGV4IDhmOWRi
MjMuLjQzZmY3MWEgMTAwNjQ0DQo+ID4gPiAtLS0gYS9kcml2ZXJzL3NvYy9mc2wvTWFrZWZpbGUN
Cj4gPiA+ICsrKyBiL2RyaXZlcnMvc29jL2ZzbC9NYWtlZmlsZQ0KPiA+ID4gQEAgLTcsMyArNyw0
IEBAIG9iai0kKENPTkZJR19RVUlDQ19FTkdJTkUpICAgICAgICAgICAgKz0gcWUvDQo+ID4gPiAg
b2JqLSQoQ09ORklHX0NQTSkgICAgICAgICAgICAgICAgICAgICs9IHFlLw0KPiA+ID4gIG9iai0k
KENPTkZJR19GU0xfR1VUUykgICAgICAgICAgICAgICAgICAgICAgICs9IGd1dHMubw0KPiA+ID4g
IG9iai0kKENPTkZJR19GU0xfUExBVF9QTSkgICAgKz0gcGxhdF9wbS5vDQo+ID4gPiArb2JqLSQo
Q09ORklHX0xTX1JDUE0pICAgICAgICAgICAgICAgICs9IGxzLXJjcG0ubw0KPiANCj4gUHJvYmFi
bHkgdXNlICJfIiBpbnN0ZWFkIG9mICItIiBmb3IgYWxpZ25tZW50Lg0KDQpPSywgd2lsbCB1cGRh
dGUgaW4gbmV4dCB2ZXJzaW9uDQoNCj4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3NvYy9mc2wv
bHMtcmNwbS5jIGIvZHJpdmVycy9zb2MvZnNsL2xzLXJjcG0uYw0KPiA+ID4gbmV3IGZpbGUgbW9k
ZSAxMDA2NDQgaW5kZXggMDAwMDAwMC4uYjBmZWI4OA0KPiA+ID4gLS0tIC9kZXYvbnVsbA0KPiA+
ID4gKysrIGIvZHJpdmVycy9zb2MvZnNsL2xzLXJjcG0uYw0KPiA+ID4gQEAgLTAsMCArMSwxNTMg
QEANCj4gPiA+ICsvLyBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMCAvLyAvLyBwbGF0
X3BtLmMgLSBGcmVlc2NhbGUNCj4gPiA+ICtMYXllcnNjYXBlIFJDUE0gZHJpdmVyDQo+IA0KPiBU
aGUgZmlsZSBuYW1lIGhlcmUgaXMgbm90IHRoZSBzYW1lIGFzIHRoZSByZWFsIGZpbGUgbmFtZS4N
Cg0KR290IGl0LCB3aWxsIGNvcnJlY3QgaXQuDQoNCj4gPiA+ICsvLw0KPiA+ID4gKy8vIENvcHly
aWdodCAyMDE4IE5YUA0KPiA+ID4gKy8vDQo+ID4gPiArLy8gQXV0aG9yOiBSYW4gV2FuZyA8cmFu
LndhbmdfMUBueHAuY29tPiwNCj4gDQo+IFdoZXJlIGRvIHlvdSBuZWVkIHRoZSBjb21tYSBpbiB0
aGUgZW5kPw0KDQpNeSBiYWQsIHdpbGwgcmVtb3ZlIGNvbW1hIGluIG5leHQgdmVyc2lvbi4NCg0K
PiA+ID4gKw0KPiA+ID4gKyNpbmNsdWRlIDxsaW51eC9pbml0Lmg+DQo+ID4gPiArI2luY2x1ZGUg
PGxpbnV4L21vZHVsZS5oPg0KPiA+ID4gKyNpbmNsdWRlIDxsaW51eC9wbGF0Zm9ybV9kZXZpY2Uu
aD4NCj4gPiA+ICsjaW5jbHVkZSA8bGludXgvb2ZfYWRkcmVzcy5oPg0KPiA+ID4gKyNpbmNsdWRl
IDxsaW51eC9zbGFiLmg+DQo+ID4gPiArI2luY2x1ZGUgPHNvYy9mc2wvcGxhdF9wbS5oPg0KPiA+
ID4gKw0KPiA+ID4gKyNkZWZpbmUgTUFYX0NPTVBBVElCTEVfTlVNICAgMTANCj4gPiA+ICsNCj4g
PiA+ICtzdHJ1Y3QgcmNwbV90IHsNCj4gPiA+ICsgICAgIHN0cnVjdCBkZXZpY2UgKmRldjsNCj4g
PiA+ICsgICAgIHZvaWQgX19pb21lbSAqaXBwZGV4cGNyX2FkZHI7DQo+ID4gPiArICAgICBib29s
IGJpZ19lbmRpYW47ICAgICAgICAvKiBCaWcvTGl0dGxlIGVuZGlhbiBvZiBSQ1BNIG1vZHVsZSAq
Lw0KPiA+ID4gK307DQo+ID4gPiArDQo+ID4gPiArLy8gcmNwbV9oYW5kbGUgLSBDb25maWd1cmUg
UkNQTSByZWcgYWNjb3JkaW5nIHRvIHdha2UgdXAgc291cmNlDQo+ID4gPiArcmVxdWVzdCAvLyBA
dXNlcl9kZXY6IHBvaW50ZXIgdG8gdXNlcidzIGRldmljZSBzdHJ1Y3QgLy8gQGZsYWc6IHRvDQo+
ID4gPiArZW5hYmxlKHRydWUpIG9yIGRpc2FibGUoZmFsc2UpIHdha2V1cCBzb3VyY2UgLy8gQGhh
bmRsZV9wcml2Og0KPiA+ID4gK3BvaW50ZXIgdG8gc3RydWN0IHJjcG1fdCBpbnN0YW5jZSAvLyAv
LyBSZXR1cm4gMCBvbiBzdWNjZXNzIG90aGVyDQo+ID4gPiArbmVnYXRpdmUgZXJybm8NCj4gDQo+
IEFsdGhvdWdoIExpbnVzIHByZWZlcnJlZCB0aGlzIC8vIGNvbW1lbnQgc3R5bGUuICBJJ20gbm90
IHN1cmUgaWYgdGhpcyB3aWxsIGJlDQo+IGhhbmRsZWQgY29ycmVjdGx5IGJ5IHRoZSBrZXJuZWwt
ZG9jIGNvbXBpbGVyLg0KPiBodHRwczovL2VtZWEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3cNCj4gdy5rZXJuZWwub3JnJTJGZG9jJTJGaHRt
bCUyRnY0LjE4JTJGZG9jLWd1aWRlJTJGa2VybmVsLQ0KPiBkb2MuaHRtbCZhbXA7ZGF0YT0wMiU3
QzAxJTdDcmFuLndhbmdfMSU0MG54cC5jb20lN0NjMGQ4OGU2NjkwMzgNCj4gNGUwMmI5NTEwOGQ2
MTJkZWMyMzUlN0M2ODZlYTFkM2JjMmI0YzZmYTkyY2Q5OWM1YzMwMTYzNSU3QzAlN0MwDQo+ICU3
QzYzNjcxNzE0NTI4NTEyNjIwMCZhbXA7c2RhdGE9SDdHa1VOT0xWRyUyRkNjWkVTemh0SEJlSENi
TzkNCj4gJTJGSzRrOUVkSDMwQ3hxMiUyQk0lM0QmYW1wO3Jlc2VydmVkPTANCg0KU28sIGRvIHlv
dSB0aGluayBJIG5lZWQgdG8gY2hhbmdlIGFsbCBjb21tZW50IHN0eWxlIGJhY2sgdG8gJy8qIC4u
LiAqLycgPw0KQWN0dWFsbHkgSSBmZWVsIGEgbGl0dGxlIGJpdCBjb25mdXNlZCBoZXJlLg0KDQpS
ZWdhcmRzLA0KUmFuDQoNCj4gPiA+ICtzdGF0aWMgaW50IHJjcG1faGFuZGxlKHN0cnVjdCBkZXZp
Y2UgKnVzZXJfZGV2LCBib29sIGZsYWcsIHZvaWQNCj4gPiA+ICsqaGFuZGxlX3ByaXYpIHsNCj4g
PiA+ICsgICAgIHN0cnVjdCByY3BtX3QgKnJjcG07DQo+ID4gPiArICAgICBib29sIGJpZ19lbmRp
YW47DQo+ID4gPiArICAgICBjb25zdCBjaGFyICAqZGV2X2NvbXBhdGlibGVfYXJyYXlbTUFYX0NP
TVBBVElCTEVfTlVNXTsNCj4gPiA+ICsgICAgIHZvaWQgX19pb21lbSAqaXBwZGV4cGNyX2FkZHI7
DQo+ID4gPiArICAgICB1MzIgaXBwZGV4cGNyOw0KPiA+ID4gKyAgICAgdTMyIHNldF9iaXQ7DQo+
ID4gPiArICAgICBpbnQgcmV0LCBudW0sIGk7DQo+ID4gPiArDQo+ID4gPiArICAgICByY3BtID0g
aGFuZGxlX3ByaXY7DQo+ID4gPiArICAgICBiaWdfZW5kaWFuID0gcmNwbS0+YmlnX2VuZGlhbjsN
Cj4gPiA+ICsgICAgIGlwcGRleHBjcl9hZGRyID0gcmNwbS0+aXBwZGV4cGNyX2FkZHI7DQo+ID4g
PiArDQo+ID4gPiArICAgICBudW0gPSBkZXZpY2VfcHJvcGVydHlfcmVhZF9zdHJpbmdfYXJyYXko
dXNlcl9kZXYsICJjb21wYXRpYmxlIiwNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICBkZXZf
Y29tcGF0aWJsZV9hcnJheSwgTUFYX0NPTVBBVElCTEVfTlVNKTsNCj4gPiA+ICsgICAgIGlmIChu
dW0gPCAwKQ0KPiA+ID4gKyAgICAgICAgICAgICByZXR1cm4gbnVtOw0KPiA+ID4gKw0KPiA+ID4g
KyAgICAgZm9yIChpID0gMDsgaSA8IG51bTsgaSsrKSB7DQo+ID4gPiArICAgICAgICAgICAgIGlm
ICghZGV2aWNlX3Byb3BlcnR5X3ByZXNlbnQocmNwbS0+ZGV2LA0KPiA+ID4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBkZXZfY29tcGF0aWJsZV9hcnJheVtpXSkpDQo+ID4g
PiArICAgICAgICAgICAgICAgICAgICAgY29udGludWU7DQo+ID4gPiArICAgICAgICAgICAgIGVs
c2Ugew0KPiA+IFJlbW92ZSB0aGlzIGVsc2UuDQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAg
cmV0ID0gZGV2aWNlX3Byb3BlcnR5X3JlYWRfdTMyKHJjcG0tPmRldiwNCj4gPiA+ICsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGV2X2NvbXBhdGlibGVfYXJyYXlbaV0sICZz
ZXRfYml0KTsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICBpZiAocmV0KQ0KPiA+ID4gKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4gPiA+ICsNCj4gPiA+ICsg
ICAgICAgICAgICAgICAgICAgICBpZiAoIWRldmljZV9wcm9wZXJ0eV9wcmVzZW50KHJjcG0tPmRl
diwNCj4gPiA+ICsNCj4gPiA+ICsgZGV2X2NvbXBhdGlibGVfYXJyYXlbaV0pKQ0KPiA+IFRoaXMg
aGFzIGJlZW4gY2hlY2tlZC4gQ29udGludWUgPyBvciByZXR1cm4gRU5PREVW77yfDQo+ID4gPiAr
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gLUVOT0RFVjsNCj4gPiA+ICsgICAg
ICAgICAgICAgICAgICAgICBlbHNlIHsNCj4gPiBSZW1vdmUgdGhpcyBlbHNlLg0KPiA+ID4gKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmV0ID0gZGV2aWNlX3Byb3BlcnR5X3JlYWRfdTMy
KHJjcG0tPmRldiwNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBkZXZfY29tcGF0aWJsZV9hcnJheVtpXSwgJnNldF9iaXQpOw0KPiA+ID4gKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaWYgKHJldCkNCj4gPiA+ICsgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4gPiA+ICsNCj4gPiA+ICsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGlmIChiaWdfZW5kaWFuKQ0KPiA+ID4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBpcHBkZXhwY3IgPSBpb3JlYWQzMmJlKGlwcGRleHBj
cl9hZGRyKTsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVsc2UNCj4gPiA+
ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXBwZGV4cGNyID0NCj4gPiA+
ICsgaW9yZWFkMzIoaXBwZGV4cGNyX2FkZHIpOw0KPiA+ID4gKw0KPiA+ID4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaWYgKGZsYWcpDQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGlwcGRleHBjciB8PSBzZXRfYml0Ow0KPiA+ID4gKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgZWxzZQ0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBpcHBkZXhwY3IgJj0gfnNldF9iaXQ7DQo+ID4gPiArDQo+ID4gPiArICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBpZiAoYmlnX2VuZGlhbikgew0KPiA+ID4gKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpb3dyaXRlMzJiZShpcHBkZXhwY3IsIGlwcGRl
eHBjcl9hZGRyKTsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
aXBwZGV4cGNyID0gaW9yZWFkMzJiZShpcHBkZXhwY3JfYWRkcik7DQo+ID4gPiArICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB9IGVsc2UNCj4gPiBpZiAoeCkgew0KPiA+IC4uLi4NCj4gPiAu
Li4uDQo+ID4gfSAgZWxzZSB7DQo+ID4NCj4gPiB9DQo+ID4gPiArICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGlvd3JpdGUzMihpcHBkZXhwY3IsDQo+ID4gPiArIGlwcGRleHBj
cl9hZGRyKTsNCj4gPiA+ICsNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJl
dHVybiAwOw0KPiA+ID4gKyAgICAgICAgICAgICAgICAgICAgIH0NCj4gPiA+ICsgICAgICAgICAg
ICAgfQ0KPiA+ID4gKyAgICAgfQ0KPiA+ID4gKw0KPiA+ID4gKyAgICAgcmV0dXJuIC1FTk9ERVY7
DQo+ID4gPiArfQ0KPiA+ID4gKw0KPiA+ID4gK3N0YXRpYyBpbnQgbHNfcmNwbV9wcm9iZShzdHJ1
Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KSB7DQo+ID4gPiArICAgICBzdHJ1Y3QgcmVzb3VyY2Ug
KnI7DQo+ID4gPiArICAgICBzdHJ1Y3QgcmNwbV90ICpyY3BtOw0KPiA+ID4gKw0KPiA+ID4gKyAg
ICAgciA9IHBsYXRmb3JtX2dldF9yZXNvdXJjZShwZGV2LCBJT1JFU09VUkNFX01FTSwgMCk7DQo+
ID4gPiArICAgICBpZiAoIXIpDQo+ID4gPiArICAgICAgICAgICAgIHJldHVybiAtRU5PREVWOw0K
PiA+ID4gKw0KPiA+ID4gKyAgICAgcmNwbSA9IGttYWxsb2Moc2l6ZW9mKCpyY3BtKSwgR0ZQX0tF
Uk5FTCk7DQo+ID4ga3phbGxvYyBpcyBiZXR0ZXIuDQo+ID4gPiArICAgICBpZiAoIXJjcG0pDQo+
ID4gPiArICAgICAgICAgICAgIHJldHVybiAtRU5PTUVNOw0KPiA+ID4gKw0KPiA+ID4gKyAgICAg
cmNwbS0+YmlnX2VuZGlhbiA9IGRldmljZV9wcm9wZXJ0eV9yZWFkX2Jvb2woJnBkZXYtPmRldiwN
Cj4gPiA+ICsgImJpZy1lbmRpYW4iKTsNCj4gPiA+ICsNCj4gPiA+ICsgICAgIHJjcG0tPmlwcGRl
eHBjcl9hZGRyID0gZGV2bV9pb3JlbWFwX3Jlc291cmNlKCZwZGV2LT5kZXYsIHIpOw0KPiA+ID4g
KyAgICAgaWYgKElTX0VSUihyY3BtLT5pcHBkZXhwY3JfYWRkcikpDQo+ID4gPiArICAgICAgICAg
ICAgIHJldHVybiBQVFJfRVJSKHJjcG0tPmlwcGRleHBjcl9hZGRyKTsNCj4gPiA+ICsNCj4gPiA+
ICsgICAgIHJjcG0tPmRldiA9ICZwZGV2LT5kZXY7DQo+ID4gPiArICAgICBwbGF0Zm9ybV9zZXRf
ZHJ2ZGF0YShwZGV2LCByY3BtKTsNCj4gPiA+ICsNCj4gPiA+ICsgICAgIHJldHVybiByZWdpc3Rl
cl9mc2xfcGxhdGZvcm1fd2FrZXVwX3NvdXJjZShyY3BtX2hhbmRsZSwgcmNwbSk7DQo+ID4gPiAr
fQ0KPiA+ID4gKw0KPiA+ID4gK3N0YXRpYyBpbnQgbHNfcmNwbV9yZW1vdmUoc3RydWN0IHBsYXRm
b3JtX2RldmljZSAqcGRldikgew0KPiA+ID4gKyAgICAgc3RydWN0IHJjcG1fdCAgICpyY3BtOw0K
PiA+IE5vdCBuZWVkIGEgdGFibGUuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gLURvbmdzaGVuZw0K
PiA+DQo+ID4gPiArDQo+ID4gPiArICAgICByY3BtID0gcGxhdGZvcm1fZ2V0X2RydmRhdGEocGRl
dik7DQo+ID4gPiArICAgICBkZXJlZ2lzdGVyX2ZzbF9wbGF0Zm9ybV93YWtldXBfc291cmNlKHJj
cG0pOw0KPiA+ID4gKyAgICAga2ZyZWUocmNwbSk7DQo+ID4gPiArDQo+ID4gPiArICAgICByZXR1
cm4gMDsNCj4gPiA+ICt9DQo+ID4gPiArDQo+ID4gPiArc3RhdGljIGNvbnN0IHN0cnVjdCBvZl9k
ZXZpY2VfaWQgbHNfcmNwbV9vZl9tYXRjaFtdID0gew0KPiA+ID4gKyAgICAgeyAuY29tcGF0aWJs
ZSA9ICJmc2wscW9yaXEtcmNwbS0yLjEiLCB9LA0KPiA+ID4gKyAgICAge30NCj4gPiA+ICt9Ow0K
PiA+ID4gK01PRFVMRV9ERVZJQ0VfVEFCTEUob2YsIGxzX3JjcG1fb2ZfbWF0Y2gpOw0KPiA+ID4g
Kw0KPiA+ID4gK3N0YXRpYyBzdHJ1Y3QgcGxhdGZvcm1fZHJpdmVyIGxzX3JjcG1fZHJpdmVyID0g
ew0KPiA+ID4gKyAgICAgLmRyaXZlciA9IHsNCj4gPiA+ICsgICAgICAgICAgICAgLm5hbWUgPSAi
bHMtcmNwbSIsDQo+ID4gPiArICAgICAgICAgICAgIC5vZl9tYXRjaF90YWJsZSA9IGxzX3JjcG1f
b2ZfbWF0Y2gsDQo+ID4gPiArICAgICB9LA0KPiA+ID4gKyAgICAgLnByb2JlID0gbHNfcmNwbV9w
cm9iZSwNCj4gPiA+ICsgICAgIC5yZW1vdmUgPSBsc19yY3BtX3JlbW92ZSwNCj4gPiA+ICt9Ow0K
PiA+ID4gKw0KPiA+ID4gK3N0YXRpYyBpbnQgX19pbml0IGxzX3JjcG1faW5pdCh2b2lkKSB7DQo+
ID4gPiArICAgICByZXR1cm4gcGxhdGZvcm1fZHJpdmVyX3JlZ2lzdGVyKCZsc19yY3BtX2RyaXZl
cik7DQo+ID4gPiArfQ0KPiA+ID4gK3N1YnN5c19pbml0Y2FsbChsc19yY3BtX2luaXQpOw0KPiA+
ID4gKw0KPiA+ID4gK3N0YXRpYyB2b2lkIF9fZXhpdCBsc19yY3BtX2V4aXQodm9pZCkgew0KPiA+
ID4gKyAgICAgcGxhdGZvcm1fZHJpdmVyX3VucmVnaXN0ZXIoJmxzX3JjcG1fZHJpdmVyKTsNCj4g
PiA+ICt9DQo+ID4gPiArbW9kdWxlX2V4aXQobHNfcmNwbV9leGl0KTsNCj4gPg0KPiA+DQo=
^ permalink raw reply
* Re: [RFC PATCH v1 00/17] ban the use of _PAGE_XXX flags outside platform specific code
From: Christophe Leroy @ 2018-09-07 9:41 UTC (permalink / raw)
To: Aneesh Kumar K.V, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, npiggin, aneesh.kumar
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <8736uneylc.fsf@linux.ibm.com>
On 09/06/2018 09:58 AM, Aneesh Kumar K.V wrote:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
>> Today flags like for instance _PAGE_RW or _PAGE_USER are used through
>> common parts of code.
>> Using those directly in common parts of code have proven to lead to
>> mistakes or misbehaviour, because their use is not always as trivial
>> as one could think.
>>
>> For instance, (flags & _PAGE_USER) == 0 isn't enough to tell
>> that a page is a kernel page, because some targets are using
>> _PAGE_PRIVILEDGED and not _PAGE_USER, so the test has to be
>> (flags & (_PAGE_USER | _PAGE_PRIVILEDGED)) == _PAGE_PRIVILEDGED
>> This has to (bad) consequences:
>>
>> - All targets must define every bit, even the unsupported ones,
>> leading to a lot of useless #define _PAGE_XXX 0
>> - If someone forgets to take into account all possible _PAGE_XXX bits
>> for the case, we can get unexpected behaviour on some targets.
>>
>> This becomes even more complex when we come to using _PAGE_RW.
>> Testing (flags & _PAGE_RW) is not enough to test whether a page
>> if writable or not, because:
>>
>> - Some targets have _PAGE_RO instead, which has to be unset to tell
>> a page is writable
>> - Some targets have _PAGE_R and _PAGE_W, in which case
>> _PAGE_RW = _PAGE_R | _PAGE_W
>> - Even knowing whether a page is readable is not always trivial because:
>> - Some targets requires to check that _PAGE_R is set to ensure page
>> is readable
>> - Some targets requires to check that _PAGE_NA is not set
>> - Some targets requires to check that _PAGE_RO or _PAGE_RW is set
>>
>> Etc ....
>>
>> In order to work around all those issues and minimise the risks of errors,
>> this serie aims at removing all use of _PAGE_XXX flags from powerpc code
>> and always use pte_xxx() and pte_mkxxx() accessors instead. Those accessors
>> are then defined in target specific parts of the kernel code.
>
> The series is really good. It also helps in code readability. Few things
> i am not sure there is a way to reduce the overhead
>
> - access = _PAGE_EXEC;
> + access = pte_val(pte_mkexec(__pte(0)));
>
> Considering we have multiple big endian to little endian coversion there
> for book3s 64.
Thanks for the review.
For the above, I propose the following:
diff --git a/arch/powerpc/mm/hash_utils_64.c
b/arch/powerpc/mm/hash_utils_64.c
index f23a89d8e4ce..904ac9c84ea5 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1482,7 +1482,7 @@ static bool should_hash_preload(struct mm_struct
*mm, unsigned long ea)
#endif
void hash_preload(struct mm_struct *mm, unsigned long ea,
- unsigned long access, unsigned long trap)
+ bool is_exec, unsigned long trap)
{
int hugepage_shift;
unsigned long vsid;
@@ -1490,6 +1490,7 @@ void hash_preload(struct mm_struct *mm, unsigned
long ea,
pte_t *ptep;
unsigned long flags;
int rc, ssize, update_flags = 0;
+ unsigned long access = is_exec ? _PAGE_EXEC : 0;
BUG_ON(REGION_ID(ea) != USER_REGION_ID);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 5c8530d0c611..4122f26a2f44 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -507,7 +507,8 @@ void update_mmu_cache(struct vm_area_struct *vma,
unsigned long address,
* We don't need to worry about _PAGE_PRESENT here because we are
* called with either mm->page_table_lock held or ptl lock held
*/
- unsigned long access, trap;
+ unsigned long trap;
+ bool is_exec;
if (radix_enabled()) {
prefetch((void *)address);
@@ -529,10 +530,10 @@ void update_mmu_cache(struct vm_area_struct *vma,
unsigned long address,
trap = current->thread.regs ? TRAP(current->thread.regs) : 0UL;
switch (trap) {
case 0x300:
- access = 0UL;
+ is_exec = false;
break;
case 0x400:
- access = _PAGE_EXEC;
+ is_exec = true;
break;
default:
return;
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index e5d779eed181..dd7f9b951d25 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -82,7 +82,7 @@ static inline void _tlbivax_bcast(unsigned long
address, unsigned int pid,
#else /* CONFIG_PPC_MMU_NOHASH */
extern void hash_preload(struct mm_struct *mm, unsigned long ea,
- unsigned long access, unsigned long trap);
+ bool is_exec, unsigned long trap);
extern void _tlbie(unsigned long address);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index f983ffa24aa0..506e5c3e96da 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -263,7 +263,7 @@ static void __init __mapin_ram_chunk(unsigned long
offset, unsigned long top)
map_kernel_page(v, p, f);
#ifdef CONFIG_PPC_STD_MMU_32
if (ktext)
- hash_preload(&init_mm, v, 0, 0x300);
+ hash_preload(&init_mm, v, false, 0x300);
#endif
v += PAGE_SIZE;
p += PAGE_SIZE;
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index bea6c544e38f..38a793bfca37 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -163,7 +163,7 @@ void __init setbat(int index, unsigned long virt,
phys_addr_t phys,
* Preload a translation in the hash table
*/
void hash_preload(struct mm_struct *mm, unsigned long ea,
- unsigned long access, unsigned long trap)
+ bool is_exec, unsigned long trap)
{
pmd_t *pmd;
>
> Other thing is __ioremap_at where we do
>
> + pte_t pte = __pte(flags);
>
> /* Make sure we have the base flags */
> - if ((flags & _PAGE_PRESENT) == 0)
> + if (!pte_present(pte))
This one is using pte_raw(), so shouldn't be a problem.
Since the function is doing almost nothing of on the flags, maybe
we could just replace the above by pte_present(__pte(flags)) and
leave the rest as is.
>
> - err = map_kernel_page(v+i, p+i, flags);
> + err = map_kernel_page(v + i, p + i, pte_val(pte));
Maybe another alternative would be to pass a pte_t to map_kernel_page(),
then we have to find an optimised way to insert the RPN into it before
calling set_pte_at() instead of using pfn_pte() ?
If we are so concerned by the multiple conversions, should we modify all
the pte_mkxxxx() to use pte_raw() and __pte_raw() instead of pte_val()
and __pte() ?
>
>
> But otherwise for the series.
>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>
Thanks
Christophe
^ permalink raw reply related
* RE: [PATCH 3/3] soc: fsl: add RCPM driver
From: Ran Wang @ 2018-09-07 9:32 UTC (permalink / raw)
To: Wang, Dongsheng, 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
In-Reply-To: <be39f5ea8c9046b0bf1f6bbfe935fae4@HXTBJIDCEMVIW02.hxtcorp.net>
SGkgRG9uZ3NoZW5nLA0KDQpPbiAyMDE4LzkvNSAxMDo1OCwgRG9uZ3NoZW5nIFdhbmcgd3JvdGU6
DQo+IA0KPiBQbGVhc2UgY2hhbmdlIHlvdXIgY29tbWVudHMgc3R5bGUuDQo+IA0KPiBPbiAyMDE4
LzgvMzEgMTE6NTYsIFJhbiBXYW5nIHdyb3RlOg0KPiA+IFRoZSBOWFAncyBRb3JJUSBQcm9jZXNz
b3JzIGJhc2VkIG9uIEFSTSBDb3JlIGhhdmUgUkNQTSBtb2R1bGUgKFJ1bg0KPiA+IENvbnRyb2wg
YW5kIFBvd2VyIE1hbmFnZW1lbnQpLCB3aGljaCBwZXJmb3JtcyBhbGwgZGV2aWNlLWxldmVsIHRh
c2tzDQo+ID4gYXNzb2NpYXRlZCB3aXRoIHBvd2VyIG1hbmFnZW1lbnQgc3VjaCBhcyB3YWtldXAg
c291cmNlIGNvbnRyb2wuDQo+ID4NCj4gPiBUaGlzIGRyaXZlciBkZXBlbmRzIG9uIEZTTCBwbGF0
Zm9ybSBQTSBkcml2ZXIgZnJhbWV3b3JrIHdoaWNoIGhlbHAgdG8NCj4gPiBpc29sYXRlIHVzZXIg
YW5kIFBNIHNlcnZpY2UgcHJvdmlkZXIgKHN1Y2ggYXMgUkNQTSBkcml2ZXIpLg0KPiA+DQo+ID4g
U2lnbmVkLW9mZi1ieTogQ2hlbmh1aSBaaGFvIDxjaGVuaHVpLnpoYW9AbnhwLmNvbT4NCj4gPiBT
aWduZWQtb2ZmLWJ5OiBZaW5nIFpoYW5nIDx5aW5nLnpoYW5nMjI0NTVAbnhwLmNvbT4NCj4gPiBT
aWduZWQtb2ZmLWJ5OiBSYW4gV2FuZyA8cmFuLndhbmdfMUBueHAuY29tPg0KPiA+IC0tLQ0KPiA+
ICBkcml2ZXJzL3NvYy9mc2wvS2NvbmZpZyAgIHwgICAgNiArKw0KPiA+ICBkcml2ZXJzL3NvYy9m
c2wvTWFrZWZpbGUgIHwgICAgMSArDQo+ID4gIGRyaXZlcnMvc29jL2ZzbC9scy1yY3BtLmMgfCAg
MTUzDQo+ID4gKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+
ID4gIDMgZmlsZXMgY2hhbmdlZCwgMTYwIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pICBj
cmVhdGUgbW9kZQ0KPiA+IDEwMDY0NCBkcml2ZXJzL3NvYy9mc2wvbHMtcmNwbS5jDQo+ID4NCj4g
PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9zb2MvZnNsL0tjb25maWcgYi9kcml2ZXJzL3NvYy9mc2wv
S2NvbmZpZyBpbmRleA0KPiA+IDY1MTc0MTIuLjg4MjMzMGQgMTAwNjQ0DQo+ID4gLS0tIGEvZHJp
dmVycy9zb2MvZnNsL0tjb25maWcNCj4gPiArKysgYi9kcml2ZXJzL3NvYy9mc2wvS2NvbmZpZw0K
PiA+IEBAIC0zMCwzICszMCw5IEBAIGNvbmZpZyBGU0xfUExBVF9QTQ0KPiA+ICAJICBoYXZlIHRv
IGtub3cgdGhlIGltcGxlbWVudCBkZXRhaWxzIG9mIHdha2V1cCBmdW5jdGlvbiBpdCByZXF1aXJl
Lg0KPiA+ICAJICBCZXNpZGVzLCBpdCBpcyBhbHNvIGVhc3kgZm9yIHNlcnZpY2Ugc2lkZSB0byB1
cGdyYWRlIGl0cyBsb2dpYyB3aGVuDQo+ID4gIAkgIGRlc2lnbiBjaGFuZ2VkIGFuZCByZW1haW4g
dXNlciBzaWRlIHVuY2hhbmdlZC4NCj4gPiArDQo+ID4gK2NvbmZpZyBMU19SQ1BNDQo+ID4gKwli
b29sICJGcmVlc2NhbGUgUkNQTSBzdXBwb3J0Ig0KPiA+ICsJZGVwZW5kcyBvbiAoRlNMX1BMQVRf
UE0pDQo+ID4gKwloZWxwDQo+ID4gKwkgIFRoaXMgZmVhdHVyZSBpcyB0byBlbmFibGUgc3BlY2lm
aWVkIHdha2V1cCBzb3VyY2UgZm9yIHN5c3RlbSBzbGVlcC4NCj4gPiBkaWZmIC0tZ2l0IGEvZHJp
dmVycy9zb2MvZnNsL01ha2VmaWxlIGIvZHJpdmVycy9zb2MvZnNsL01ha2VmaWxlIGluZGV4DQo+
ID4gOGY5ZGIyMy4uNDNmZjcxYSAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL3NvYy9mc2wvTWFr
ZWZpbGUNCj4gPiArKysgYi9kcml2ZXJzL3NvYy9mc2wvTWFrZWZpbGUNCj4gPiBAQCAtNywzICs3
LDQgQEAgb2JqLSQoQ09ORklHX1FVSUNDX0VOR0lORSkJCSs9IHFlLw0KPiA+ICBvYmotJChDT05G
SUdfQ1BNKQkJCSs9IHFlLw0KPiA+ICBvYmotJChDT05GSUdfRlNMX0dVVFMpCQkJKz0gZ3V0cy5v
DQo+ID4gIG9iai0kKENPTkZJR19GU0xfUExBVF9QTSkJKz0gcGxhdF9wbS5vDQo+ID4gK29iai0k
KENPTkZJR19MU19SQ1BNKQkJKz0gbHMtcmNwbS5vDQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMv
c29jL2ZzbC9scy1yY3BtLmMgYi9kcml2ZXJzL3NvYy9mc2wvbHMtcmNwbS5jIG5ldw0KPiA+IGZp
bGUgbW9kZSAxMDA2NDQgaW5kZXggMDAwMDAwMC4uYjBmZWI4OA0KPiA+IC0tLSAvZGV2L251bGwN
Cj4gPiArKysgYi9kcml2ZXJzL3NvYy9mc2wvbHMtcmNwbS5jDQo+ID4gQEAgLTAsMCArMSwxNTMg
QEANCj4gPiArLy8gU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjANCj4gPiArLy8NCj4g
PiArLy8gcGxhdF9wbS5jIC0gRnJlZXNjYWxlIExheWVyc2NhcGUgUkNQTSBkcml2ZXIgLy8gLy8g
Q29weXJpZ2h0IDIwMTgNCj4gPiArTlhQIC8vIC8vIEF1dGhvcjogUmFuIFdhbmcgPHJhbi53YW5n
XzFAbnhwLmNvbT4sDQo+ID4gKw0KPiA+ICsjaW5jbHVkZSA8bGludXgvaW5pdC5oPg0KPiA+ICsj
aW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQo+ID4gKyNpbmNsdWRlIDxsaW51eC9wbGF0Zm9ybV9k
ZXZpY2UuaD4NCj4gPiArI2luY2x1ZGUgPGxpbnV4L29mX2FkZHJlc3MuaD4NCj4gPiArI2luY2x1
ZGUgPGxpbnV4L3NsYWIuaD4NCj4gPiArI2luY2x1ZGUgPHNvYy9mc2wvcGxhdF9wbS5oPg0KPiA+
ICsNCj4gPiArI2RlZmluZSBNQVhfQ09NUEFUSUJMRV9OVU0JMTANCj4gPiArDQo+ID4gK3N0cnVj
dCByY3BtX3Qgew0KPiA+ICsJc3RydWN0IGRldmljZSAqZGV2Ow0KPiA+ICsJdm9pZCBfX2lvbWVt
ICppcHBkZXhwY3JfYWRkcjsNCj4gPiArCWJvb2wgYmlnX2VuZGlhbjsJLyogQmlnL0xpdHRsZSBl
bmRpYW4gb2YgUkNQTSBtb2R1bGUgKi8NCj4gPiArfTsNCj4gPiArDQo+ID4gKy8vIHJjcG1faGFu
ZGxlIC0gQ29uZmlndXJlIFJDUE0gcmVnIGFjY29yZGluZyB0byB3YWtlIHVwIHNvdXJjZQ0KPiA+
ICtyZXF1ZXN0IC8vIEB1c2VyX2RldjogcG9pbnRlciB0byB1c2VyJ3MgZGV2aWNlIHN0cnVjdCAv
LyBAZmxhZzogdG8NCj4gPiArZW5hYmxlKHRydWUpIG9yIGRpc2FibGUoZmFsc2UpIHdha2V1cCBz
b3VyY2UgLy8gQGhhbmRsZV9wcml2OiBwb2ludGVyDQo+ID4gK3RvIHN0cnVjdCByY3BtX3QgaW5z
dGFuY2UgLy8gLy8gUmV0dXJuIDAgb24gc3VjY2VzcyBvdGhlciBuZWdhdGl2ZQ0KPiA+ICtlcnJu
byBzdGF0aWMgaW50IHJjcG1faGFuZGxlKHN0cnVjdCBkZXZpY2UgKnVzZXJfZGV2LCBib29sIGZs
YWcsIHZvaWQNCj4gPiArKmhhbmRsZV9wcml2KSB7DQo+ID4gKwlzdHJ1Y3QgcmNwbV90ICpyY3Bt
Ow0KPiA+ICsJYm9vbCBiaWdfZW5kaWFuOw0KPiA+ICsJY29uc3QgY2hhciAgKmRldl9jb21wYXRp
YmxlX2FycmF5W01BWF9DT01QQVRJQkxFX05VTV07DQo+ID4gKwl2b2lkIF9faW9tZW0gKmlwcGRl
eHBjcl9hZGRyOw0KPiA+ICsJdTMyIGlwcGRleHBjcjsNCj4gPiArCXUzMiBzZXRfYml0Ow0KPiA+
ICsJaW50IHJldCwgbnVtLCBpOw0KPiA+ICsNCj4gPiArCXJjcG0gPSBoYW5kbGVfcHJpdjsNCj4g
PiArCWJpZ19lbmRpYW4gPSByY3BtLT5iaWdfZW5kaWFuOw0KPiA+ICsJaXBwZGV4cGNyX2FkZHIg
PSByY3BtLT5pcHBkZXhwY3JfYWRkcjsNCj4gPiArDQo+ID4gKwludW0gPSBkZXZpY2VfcHJvcGVy
dHlfcmVhZF9zdHJpbmdfYXJyYXkodXNlcl9kZXYsICJjb21wYXRpYmxlIiwNCj4gPiArCQkJZGV2
X2NvbXBhdGlibGVfYXJyYXksIE1BWF9DT01QQVRJQkxFX05VTSk7DQo+ID4gKwlpZiAobnVtIDwg
MCkNCj4gPiArCQlyZXR1cm4gbnVtOw0KPiA+ICsNCj4gPiArCWZvciAoaSA9IDA7IGkgPCBudW07
IGkrKykgew0KPiA+ICsJCWlmICghZGV2aWNlX3Byb3BlcnR5X3ByZXNlbnQocmNwbS0+ZGV2LA0K
PiA+ICsJCQkJCWRldl9jb21wYXRpYmxlX2FycmF5W2ldKSkNCj4gPiArCQkJY29udGludWU7DQo+
ID4gKwkJZWxzZSB7DQo+IFJlbW92ZSB0aGlzIGVsc2UuDQoNCkdvdCBpdCEgV2lsbCB1cGRhdGUg
aW4gbmV4dCB2ZXJzaW9uLg0KDQo+ID4gKwkJCXJldCA9IGRldmljZV9wcm9wZXJ0eV9yZWFkX3Uz
MihyY3BtLT5kZXYsDQo+ID4gKwkJCQkJZGV2X2NvbXBhdGlibGVfYXJyYXlbaV0sICZzZXRfYml0
KTsNCj4gPiArCQkJaWYgKHJldCkNCj4gPiArCQkJCXJldHVybiByZXQ7DQo+ID4gKw0KPiA+ICsJ
CQlpZiAoIWRldmljZV9wcm9wZXJ0eV9wcmVzZW50KHJjcG0tPmRldiwNCj4gPiArCQkJCQkJZGV2
X2NvbXBhdGlibGVfYXJyYXlbaV0pKQ0KPiBUaGlzIGhhcyBiZWVuIGNoZWNrZWQuIENvbnRpbnVl
ID8gb3IgcmV0dXJuIEVOT0RFVqO/DQoNClllcywgdGhpcyBjaGVja2luZyBpcyBub3QgbmVjZXNz
YXJ5LCB3aWxsIHJlbW92ZSBpbiBuZXh0IHZlcnNpb24NCg0KPiA+ICsJCQkJcmV0dXJuIC1FTk9E
RVY7DQo+ID4gKwkJCWVsc2Ugew0KPiBSZW1vdmUgdGhpcyBlbHNlLg0KDQpPSw0KDQo+ID4gKwkJ
CQlyZXQgPSBkZXZpY2VfcHJvcGVydHlfcmVhZF91MzIocmNwbS0+ZGV2LA0KPiA+ICsJCQkJCQlk
ZXZfY29tcGF0aWJsZV9hcnJheVtpXSwNCj4gJnNldF9iaXQpOw0KPiA+ICsJCQkJaWYgKHJldCkN
Cj4gPiArCQkJCQlyZXR1cm4gcmV0Ow0KPiA+ICsNCj4gPiArCQkJCWlmIChiaWdfZW5kaWFuKQ0K
PiA+ICsJCQkJCWlwcGRleHBjciA9DQo+IGlvcmVhZDMyYmUoaXBwZGV4cGNyX2FkZHIpOw0KPiA+
ICsJCQkJZWxzZQ0KPiA+ICsJCQkJCWlwcGRleHBjciA9DQo+IGlvcmVhZDMyKGlwcGRleHBjcl9h
ZGRyKTsNCj4gPiArDQo+ID4gKwkJCQlpZiAoZmxhZykNCj4gPiArCQkJCQlpcHBkZXhwY3IgfD0g
c2V0X2JpdDsNCj4gPiArCQkJCWVsc2UNCj4gPiArCQkJCQlpcHBkZXhwY3IgJj0gfnNldF9iaXQ7
DQo+ID4gKw0KPiA+ICsJCQkJaWYgKGJpZ19lbmRpYW4pIHsNCj4gPiArCQkJCQlpb3dyaXRlMzJi
ZShpcHBkZXhwY3IsDQo+IGlwcGRleHBjcl9hZGRyKTsNCj4gPiArCQkJCQlpcHBkZXhwY3IgPQ0K
PiBpb3JlYWQzMmJlKGlwcGRleHBjcl9hZGRyKTsNCj4gPiArCQkJCX0gZWxzZQ0KPiBpZiAoeCkg
ew0KPiAuLi4uDQo+IC4uLi4NCj4gfSAgZWxzZSB7DQo+IA0KPiB9DQoNCkdvdCBpdCENCg0KPiA+
ICsJCQkJCWlvd3JpdGUzMihpcHBkZXhwY3IsIGlwcGRleHBjcl9hZGRyKTsNCj4gPiArDQo+ID4g
KwkJCQlyZXR1cm4gMDsNCj4gPiArCQkJfQ0KPiA+ICsJCX0NCj4gPiArCX0NCj4gPiArDQo+ID4g
KwlyZXR1cm4gLUVOT0RFVjsNCj4gPiArfQ0KPiA+ICsNCj4gPiArc3RhdGljIGludCBsc19yY3Bt
X3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpIHsNCj4gPiArCXN0cnVjdCByZXNv
dXJjZSAqcjsNCj4gPiArCXN0cnVjdCByY3BtX3QgKnJjcG07DQo+ID4gKw0KPiA+ICsJciA9IHBs
YXRmb3JtX2dldF9yZXNvdXJjZShwZGV2LCBJT1JFU09VUkNFX01FTSwgMCk7DQo+ID4gKwlpZiAo
IXIpDQo+ID4gKwkJcmV0dXJuIC1FTk9ERVY7DQo+ID4gKw0KPiA+ICsJcmNwbSA9IGttYWxsb2Mo
c2l6ZW9mKCpyY3BtKSwgR0ZQX0tFUk5FTCk7DQo+IGt6YWxsb2MgaXMgYmV0dGVyLg0KDQpPSw0K
DQo+ID4gKwlpZiAoIXJjcG0pDQo+ID4gKwkJcmV0dXJuIC1FTk9NRU07DQo+ID4gKw0KPiA+ICsJ
cmNwbS0+YmlnX2VuZGlhbiA9IGRldmljZV9wcm9wZXJ0eV9yZWFkX2Jvb2woJnBkZXYtPmRldiwN
Cj4gPiArImJpZy1lbmRpYW4iKTsNCj4gPiArDQo+ID4gKwlyY3BtLT5pcHBkZXhwY3JfYWRkciA9
IGRldm1faW9yZW1hcF9yZXNvdXJjZSgmcGRldi0+ZGV2LCByKTsNCj4gPiArCWlmIChJU19FUlIo
cmNwbS0+aXBwZGV4cGNyX2FkZHIpKQ0KPiA+ICsJCXJldHVybiBQVFJfRVJSKHJjcG0tPmlwcGRl
eHBjcl9hZGRyKTsNCj4gPiArDQo+ID4gKwlyY3BtLT5kZXYgPSAmcGRldi0+ZGV2Ow0KPiA+ICsJ
cGxhdGZvcm1fc2V0X2RydmRhdGEocGRldiwgcmNwbSk7DQo+ID4gKw0KPiA+ICsJcmV0dXJuIHJl
Z2lzdGVyX2ZzbF9wbGF0Zm9ybV93YWtldXBfc291cmNlKHJjcG1faGFuZGxlLCByY3BtKTsgfQ0K
PiA+ICsNCj4gPiArc3RhdGljIGludCBsc19yY3BtX3JlbW92ZShzdHJ1Y3QgcGxhdGZvcm1fZGV2
aWNlICpwZGV2KSB7DQo+ID4gKwlzdHJ1Y3QgcmNwbV90CSpyY3BtOw0KPiBOb3QgbmVlZCBhIHRh
YmxlLg0KDQpPSywgdGhhbmtzIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3Lg0KDQpSZWdhcmRzLA0K
UmFuDQogDQoNCj4gQ2hlZXJzLA0KPiAtRG9uZ3NoZW5nDQo+IA0KPiA+ICsNCj4gPiArCXJjcG0g
PSBwbGF0Zm9ybV9nZXRfZHJ2ZGF0YShwZGV2KTsNCj4gPiArCWRlcmVnaXN0ZXJfZnNsX3BsYXRm
b3JtX3dha2V1cF9zb3VyY2UocmNwbSk7DQo+ID4gKwlrZnJlZShyY3BtKTsNCj4gPiArDQo+ID4g
KwlyZXR1cm4gMDsNCj4gPiArfQ0KPiA+ICsNCj4gPiArc3RhdGljIGNvbnN0IHN0cnVjdCBvZl9k
ZXZpY2VfaWQgbHNfcmNwbV9vZl9tYXRjaFtdID0gew0KPiA+ICsJeyAuY29tcGF0aWJsZSA9ICJm
c2wscW9yaXEtcmNwbS0yLjEiLCB9LA0KPiA+ICsJe30NCj4gPiArfTsNCj4gPiArTU9EVUxFX0RF
VklDRV9UQUJMRShvZiwgbHNfcmNwbV9vZl9tYXRjaCk7DQo+ID4gKw0KPiA+ICtzdGF0aWMgc3Ry
dWN0IHBsYXRmb3JtX2RyaXZlciBsc19yY3BtX2RyaXZlciA9IHsNCj4gPiArCS5kcml2ZXIgPSB7
DQo+ID4gKwkJLm5hbWUgPSAibHMtcmNwbSIsDQo+ID4gKwkJLm9mX21hdGNoX3RhYmxlID0gbHNf
cmNwbV9vZl9tYXRjaCwNCj4gPiArCX0sDQo+ID4gKwkucHJvYmUgPSBsc19yY3BtX3Byb2JlLA0K
PiA+ICsJLnJlbW92ZSA9IGxzX3JjcG1fcmVtb3ZlLA0KPiA+ICt9Ow0KPiA+ICsNCj4gPiArc3Rh
dGljIGludCBfX2luaXQgbHNfcmNwbV9pbml0KHZvaWQpDQo+ID4gK3sNCj4gPiArCXJldHVybiBw
bGF0Zm9ybV9kcml2ZXJfcmVnaXN0ZXIoJmxzX3JjcG1fZHJpdmVyKTsNCj4gPiArfQ0KPiA+ICtz
dWJzeXNfaW5pdGNhbGwobHNfcmNwbV9pbml0KTsNCj4gPiArDQo+ID4gK3N0YXRpYyB2b2lkIF9f
ZXhpdCBsc19yY3BtX2V4aXQodm9pZCkgew0KPiA+ICsJcGxhdGZvcm1fZHJpdmVyX3VucmVnaXN0
ZXIoJmxzX3JjcG1fZHJpdmVyKTsNCj4gPiArfQ0KPiA+ICttb2R1bGVfZXhpdChsc19yY3BtX2V4
aXQpOw0KPiANCg0K
^ permalink raw reply
* Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
From: Mike Rapoport @ 2018-09-07 9:19 UTC (permalink / raw)
To: Michal Hocko
Cc: Rob Herring, linux-mm, Andrew Morton, davem, Greg Kroah-Hartman,
mingo, Michael Ellerman, paul.burton, Thomas Gleixner, tony.luck,
linux-ia64, linux-mips, linuxppc-dev, sparclinux,
Linux Kernel Mailing List
In-Reply-To: <20180907084756.GD19621@dhcp22.suse.cz>
On Fri, Sep 07, 2018 at 10:47:56AM +0200, Michal Hocko wrote:
> On Fri 07-09-18 11:42:12, Mike Rapoport wrote:
> > On Thu, Sep 06, 2018 at 03:46:27PM +0200, Michal Hocko wrote:
> > > On Thu 06-09-18 16:39:58, Mike Rapoport wrote:
> > > > On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote:
> > > > > On Thu 06-09-18 15:43:21, Mike Rapoport wrote:
> > > > > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote:
> > > > > > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote:
> > > > > > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote:
> > > > > > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> > > > > > > > > >
> > > > > > > > > > The conversion is done using
> > > > > > > > > >
> > > > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \
> > > > > > > > > > $(git grep -l memblock_virt_alloc)
> > > > > > > > >
> > > > > > > > > What's the reason to do this? It seems like a lot of churn even if a
> > > > > > > > > mechanical change.
> > > > > > > >
> > > > > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g:
> > > > > > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic.
> > > > > > > >
> > > > > > > > And for consistency I've changed the memblock_virt_alloc as well.
> > > > > > >
> > > > > > > I would keep the current API unless the name is terribly misleading or
> > > > > > > it can be improved a lot. Neither seems to be the case here. So I would
> > > > > > > rather stick with the status quo.
> > > > > >
> > > > > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in
> > > > > > 'memblock_virt_alloc_try_nid_nopanic' and 'memblock_virt_alloc_low_nopanic'
> > > > > > reduces code readability in my opinion.
> > > > >
> > > > > Well, is _nopanic really really useful in the name. Do we even need/want
> > > > > implicit panic/nopanic semantic? The code should rather check for the
> > > > > return value and decide depending on the code path. I suspect removing
> > > > > panic/nopanic would make the API slightly lighter.
> > > >
> > > > I agree that panic/nopanic should be removed. But I prefer to start with
> > > > equivalent replacement to make it as automated as possible and update
> > > > memblock API when the dust settles a bit.
> > >
> > > Yes, I agree with that approach. But that also doesn't justify the
> > > renaming
> >
> > Well, the renaming is automated :)
>
> Yes, it is. It also adds churn to the code so I tend to prefer an
> existing naming unless it is completely misleading or incomprehensible.
>
> Is this something to lose sleep over. Absolutely not! Does it make sense
> to discuss further? I do not think so. If you strongly believe that the
> renaming is a good thing then just do it.
I won't lose my sleep over it, but I do believe that renaming is a good thing.
I think that in the end we'll be able to reduce the memblock allocation API
to a handful of memblock_alloc_ variants instead of ~20 we have now.
> --
> Michal Hocko
> SUSE Labs
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [RFC PATCH V2 4/4] powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_get
From: Michal Hocko @ 2018-09-07 9:03 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: akpm, Alexey Kardashevskiy, mpe, linux-mm, linux-kernel,
linuxppc-dev
In-Reply-To: <50d355bf-17d0-ee01-ec35-7f04e79ca277@linux.ibm.com>
On Thu 06-09-18 19:00:43, Aneesh Kumar K.V wrote:
> On 09/06/2018 06:23 PM, Michal Hocko wrote:
> > On Thu 06-09-18 11:13:42, Aneesh Kumar K.V wrote:
> > > Current code doesn't do page migration if the page allocated is a compound page.
> > > With HugeTLB migration support, we can end up allocating hugetlb pages from
> > > CMA region. Also THP pages can be allocated from CMA region. This patch updates
> > > the code to handle compound pages correctly.
> > >
> > > This use the new helper get_user_pages_cma_migrate. It does one get_user_pages
> > > with right count, instead of doing one get_user_pages per page. That avoids
> > > reading page table multiple times.
> > >
> > > The patch also convert the hpas member of mm_iommu_table_group_mem_t to a union.
> > > We use the same storage location to store pointers to struct page. We cannot
> > > update alll the code path use struct page *, because we access hpas in real mode
> > > and we can't do that struct page * to pfn conversion in real mode.
> >
> > I am not fmailiar with this code so bear with me. I am completely
> > missing the purpose of this patch. The changelog doesn't really explain
> > that AFAICS. I can only guess that you do not want to establish long
> > pins on CMA pages, right? So whenever you are about to pin a page that
> > is in CMA you migrate it away to a different !__GFP_MOVABLE page, right?
>
> That is right.
>
> > If that is the case then how do you handle pins which are already in
> > zone_movable? I do not see any specific check for those.
>
>
> >
> > Btw. why is this a proper thing to do? Problems with longterm pins are
> > not only for CMA/ZONE_MOVABLE pages. Pinned pages are not reclaimable as
> > well so there is a risk of OOMs if there are too many of them. We have
> > discussed approaches that would allow to force pin invalidation/revocation
> > at LSF/MM. Isn't that a more appropriate solution to the problem you are
> > seeing?
> >
>
> The CMA area is used on powerpc platforms to allocate guest specific page
> table (hash page table). If we don't have sufficient free pages we fail to
> allocate hash page table that result in failure to start guest.
>
> Now with vfio, we end up pinning the entire guest RAM. There is a
> possibility that these guest RAM pages got allocated from CMA region. We
> already do supporting migrating those pages out except for compound pages.
> What this patch does is to start supporting compound page migration that got
> allocated out of CMA region (ie, THP pages and hugetlb pages if platform
> supported hugetlb migration).
This definitely belongs to the changelog.
> Now to do that I added a helper get_user_pages_cma_migrate().
>
> I agree that long term pinned pages do have other issues. The patchset is
> not solving that issue.
It would be great to note why a generic approach is not viable. I assume
the main reason is that those pins are pretty much permanent for the
guest lifetime so the situation has to be handled in advance. In other
words, more information please.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
From: Michal Hocko @ 2018-09-07 8:47 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rob Herring, linux-mm, Andrew Morton, davem, Greg Kroah-Hartman,
mingo, Michael Ellerman, paul.burton, Thomas Gleixner, tony.luck,
linux-ia64, linux-mips, linuxppc-dev, sparclinux,
Linux Kernel Mailing List
In-Reply-To: <20180907084211.GA19153@rapoport-lnx>
On Fri 07-09-18 11:42:12, Mike Rapoport wrote:
> On Thu, Sep 06, 2018 at 03:46:27PM +0200, Michal Hocko wrote:
> > On Thu 06-09-18 16:39:58, Mike Rapoport wrote:
> > > On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote:
> > > > On Thu 06-09-18 15:43:21, Mike Rapoport wrote:
> > > > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote:
> > > > > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote:
> > > > > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote:
> > > > > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> > > > > > > > >
> > > > > > > > > The conversion is done using
> > > > > > > > >
> > > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \
> > > > > > > > > $(git grep -l memblock_virt_alloc)
> > > > > > > >
> > > > > > > > What's the reason to do this? It seems like a lot of churn even if a
> > > > > > > > mechanical change.
> > > > > > >
> > > > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g:
> > > > > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic.
> > > > > > >
> > > > > > > And for consistency I've changed the memblock_virt_alloc as well.
> > > > > >
> > > > > > I would keep the current API unless the name is terribly misleading or
> > > > > > it can be improved a lot. Neither seems to be the case here. So I would
> > > > > > rather stick with the status quo.
> > > > >
> > > > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in
> > > > > 'memblock_virt_alloc_try_nid_nopanic' and 'memblock_virt_alloc_low_nopanic'
> > > > > reduces code readability in my opinion.
> > > >
> > > > Well, is _nopanic really really useful in the name. Do we even need/want
> > > > implicit panic/nopanic semantic? The code should rather check for the
> > > > return value and decide depending on the code path. I suspect removing
> > > > panic/nopanic would make the API slightly lighter.
> > >
> > > I agree that panic/nopanic should be removed. But I prefer to start with
> > > equivalent replacement to make it as automated as possible and update
> > > memblock API when the dust settles a bit.
> >
> > Yes, I agree with that approach. But that also doesn't justify the
> > renaming
>
> Well, the renaming is automated :)
Yes, it is. It also adds churn to the code so I tend to prefer an
existing naming unless it is completely misleading or incomprehensible.
Is this something to lose sleep over. Absolutely not! Does it make sense
to discuss further? I do not think so. If you strongly believe that the
renaming is a good thing then just do it.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
From: Mike Rapoport @ 2018-09-07 8:42 UTC (permalink / raw)
To: Michal Hocko
Cc: Rob Herring, linux-mm, Andrew Morton, davem, Greg Kroah-Hartman,
mingo, Michael Ellerman, paul.burton, Thomas Gleixner, tony.luck,
linux-ia64, linux-mips, linuxppc-dev, sparclinux,
Linux Kernel Mailing List
In-Reply-To: <20180906134627.GZ14951@dhcp22.suse.cz>
On Thu, Sep 06, 2018 at 03:46:27PM +0200, Michal Hocko wrote:
> On Thu 06-09-18 16:39:58, Mike Rapoport wrote:
> > On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote:
> > > On Thu 06-09-18 15:43:21, Mike Rapoport wrote:
> > > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote:
> > > > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote:
> > > > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote:
> > > > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> > > > > > > >
> > > > > > > > The conversion is done using
> > > > > > > >
> > > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \
> > > > > > > > $(git grep -l memblock_virt_alloc)
> > > > > > >
> > > > > > > What's the reason to do this? It seems like a lot of churn even if a
> > > > > > > mechanical change.
> > > > > >
> > > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g:
> > > > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic.
> > > > > >
> > > > > > And for consistency I've changed the memblock_virt_alloc as well.
> > > > >
> > > > > I would keep the current API unless the name is terribly misleading or
> > > > > it can be improved a lot. Neither seems to be the case here. So I would
> > > > > rather stick with the status quo.
> > > >
> > > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in
> > > > 'memblock_virt_alloc_try_nid_nopanic' and 'memblock_virt_alloc_low_nopanic'
> > > > reduces code readability in my opinion.
> > >
> > > Well, is _nopanic really really useful in the name. Do we even need/want
> > > implicit panic/nopanic semantic? The code should rather check for the
> > > return value and decide depending on the code path. I suspect removing
> > > panic/nopanic would make the API slightly lighter.
> >
> > I agree that panic/nopanic should be removed. But I prefer to start with
> > equivalent replacement to make it as automated as possible and update
> > memblock API when the dust settles a bit.
>
> Yes, I agree with that approach. But that also doesn't justify the
> renaming
Well, the renaming is automated :)
Anyway, we can continue arguing about keeping or removing _virt regardless
of the bootmem -> memblock change. I'll redo the set with
memblock_virt_alloc and we can resume the argument later on :)
> --
> Michal Hocko
> SUSE Labs
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* RE: [PATCH 1/3] soc: fsl: add Platform PM driver QorIQ platforms
From: Ran Wang @ 2018-09-07 8:41 UTC (permalink / raw)
To: Wang, Dongsheng
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Leo Li, Rob Herring,
Mark Rutland
In-Reply-To: <366f03eab44e489b9fef82fb8e8f3c3b@HXTBJIDCEMVIW02.hxtcorp.net>
Hi Dongsheng
> On 2018/9/5 11:05, Dongsheng Wang wrote:
>=20
> Please change your comments style.
>=20
> On 2018/8/31 11:57, Ran Wang wrote:
> > This driver is to provide a independent framework for PM service
> > provider and consumer to configure system level wake up feature. For
> > example, RCPM driver could register a callback function on this
> > platform first, and Flex timer driver who want to enable timer wake up
> > feature, will call generic API provided by this platform driver, and
> > then it will trigger RCPM driver to do it. The benefit is to isolate
> > the user and service, such as flex timer driver will not have to know
> > the implement details of wakeup function it require. Besides, it is
> > also easy for service side to upgrade its logic when design is changed
> > and remain user side unchanged.
> >
> > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > ---
> > drivers/soc/fsl/Kconfig | 14 +++++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/plat_pm.c | 144
> +++++++++++++++++++++++++++++++++++++++++++++
> > include/soc/fsl/plat_pm.h | 22 +++++++
> > 4 files changed, 181 insertions(+), 0 deletions(-) create mode
> > 100644 drivers/soc/fsl/plat_pm.c create mode 100644
> > include/soc/fsl/plat_pm.h
> >
> > diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig index
> > 7a9fb9b..6517412 100644
> > --- a/drivers/soc/fsl/Kconfig
> > +++ b/drivers/soc/fsl/Kconfig
> > @@ -16,3 +16,17 @@ config FSL_GUTS
> > Initially only reading SVR and registering soc device are supported=
.
> > Other guts accesses, such as reading RCW, should eventually be
> moved
> > into this driver as well.
> > +
> > +config FSL_PLAT_PM
> > + bool "Freescale platform PM framework"
> > + help
> > + This driver is to provide a independent framework for PM service
> > + provider and consumer to configure system level wake up feature.
> For
> > + example, RCPM driver could register a callback function on this
> > + platform first, and Flex timer driver who want to enable timer wake
> > + up feature, will call generic API provided by this platform driver,
> > + and then it will trigger RCPM driver to do it. The benefit is to
> > + isolate the user and service, such as flex timer driver will not
> > + have to know the implement details of wakeup function it require.
> > + Besides, it is also easy for service side to upgrade its logic when
> > + design changed and remain user side unchanged.
> > diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile index
> > 44b3beb..8f9db23 100644
> > --- a/drivers/soc/fsl/Makefile
> > +++ b/drivers/soc/fsl/Makefile
> > @@ -6,3 +6,4 @@ obj-$(CONFIG_FSL_DPAA) +=3D qbman/
> > obj-$(CONFIG_QUICC_ENGINE) +=3D qe/
> > obj-$(CONFIG_CPM) +=3D qe/
> > obj-$(CONFIG_FSL_GUTS) +=3D guts.o
> > +obj-$(CONFIG_FSL_PLAT_PM) +=3D plat_pm.o
> > diff --git a/drivers/soc/fsl/plat_pm.c b/drivers/soc/fsl/plat_pm.c new
> > file mode 100644 index 0000000..19ea14e
> > --- /dev/null
> > +++ b/drivers/soc/fsl/plat_pm.c
> > @@ -0,0 +1,144 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// plat_pm.c - Freescale platform PM framework // // Copyright 2018
> > +NXP // // Author: Ran Wang <ran.wang_1@nxp.com>,
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/device.h>
> > +#include <linux/list.h>
> > +#include <linux/slab.h>
> > +#include <linux/err.h>
> > +#include <soc/fsl/plat_pm.h>
> > +
> > +
> > +struct plat_pm_t {
> > + struct list_head node;
> > + fsl_plat_pm_handle handle;
> > + void *handle_priv;
> > + spinlock_t lock;
> > +};
> > +
> > +static struct plat_pm_t plat_pm;
> > +
> > +// register_fsl_platform_wakeup_source - Register callback function
> > +to plat_pm // @handle: Pointer to handle PM feature requirement //
> > +@handle_priv: Handler specific data struct // // Return 0 on success
> > +other negative errno int
> > +register_fsl_platform_wakeup_source(fsl_plat_pm_handle handle,
> > + void *handle_priv)
> > +{
> > + struct plat_pm_t *p;
> > + unsigned long flags;
> > +
> > + if (!handle) {
> > + pr_err("FSL plat_pm: Handler invalid, reject\n");
> > + return -EINVAL;
> > + }
> > +
> > + p =3D kmalloc(sizeof(*p), GFP_KERNEL);
> > + if (!p)
> > + return -ENOMEM;
> > +
> > + p->handle =3D handle;
> > + p->handle_priv =3D handle_priv;
> > +
> > + spin_lock_irqsave(&plat_pm.lock, flags);
> > + list_add_tail(&p->node, &plat_pm.node);
> > + spin_unlock_irqrestore(&plat_pm.lock, flags);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(register_fsl_platform_wakeup_source);
> > +
> > +// Deregister_fsl_platform_wakeup_source - deregister callback
> > +function // @handle_priv: Handler specific data struct // // Return 0
> > +on success other negative errno int
> > +deregister_fsl_platform_wakeup_source(void *handle_priv) {
> > + struct plat_pm_t *p, *tmp;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&plat_pm.lock, flags);
> > + list_for_each_entry_safe(p, tmp, &plat_pm.node, node) {
> > + if (p->handle_priv =3D=3D handle_priv) {
> > + list_del(&p->node);
> > + kfree(p);
> > + }
> > + }
> > + spin_unlock_irqrestore(&plat_pm.lock, flags);
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(deregister_fsl_platform_wakeup_source);
> > +
> > +// fsl_platform_wakeup_config - Configure wakeup source by calling
> > +handlers // @dev: pointer to user's device struct // @flag: to tell
> > +enable or disable wakeup source // // Return 0 on success other
> > +negative errno int fsl_platform_wakeup_config(struct device *dev,
> > +bool flag) {
> > + struct plat_pm_t *p;
> > + int ret;
> > + bool success_handled;
> > + unsigned long flags;
> > +
> > + success_handled =3D false;
> > +
> > + // Will consider success if at least one callback return 0.
> > + // Also, rest handles still get oppertunity to be executed
> > + spin_lock_irqsave(&plat_pm.lock, flags);
> > + list_for_each_entry(p, &plat_pm.node, node) {
> > + if (p->handle) {
> > + ret =3D p->handle(dev, flag, p->handle_priv);
> > + if (!ret)
> > + success_handled =3D true;
> Miss a break?
Actually my idea is to allow more than one registered handler to handle thi=
s
request, so I define a flag rather than return to indicated if there is at =
least one handler successfully
do it. This design might give more flexibility to framework when running.
> > + else if (ret !=3D -ENODEV) {
> > + pr_err("FSL plat_pm: Failed to config wakeup
> source:%d\n", ret);
> Please unlock before return.
Yes, will fix it in next version, thanks for pointing out!
> > + return ret;
> > + }
> > + } else
> > + pr_warn("FSL plat_pm: Invalid handler detected,
> skip\n");
> > + }
> > + spin_unlock_irqrestore(&plat_pm.lock, flags);
> > +
> > + if (success_handled =3D=3D false) {
> > + pr_err("FSL plat_pm: Cannot find the matchhed handler for
> wakeup source config\n");
> > + return -ENODEV;
> > + }
> Add this into the loop.
My design is that if the 1st handler return -ENODEV to indicated this devic=
e it doesn't support,=20
then the framework will continue try 2nd handler...
So I think it is needed to place this checking out of loop, what do you say=
?
Regards,
Ran
> > +
> > + return 0;
> > +}
> > +
> > +// fsl_platform_wakeup_enable - Enable wakeup source // @dev: pointer
> > +to user's device struct // // Return 0 on success other negative
> > +errno int fsl_platform_wakeup_enable(struct device *dev) {
> > + return fsl_platform_wakeup_config(dev, true); }
> > +EXPORT_SYMBOL_GPL(fsl_platform_wakeup_enable);
> > +
> > +// fsl_platform_wakeup_disable - Disable wakeup source // @dev:
> > +pointer to user's device struct // // Return 0 on success other
> > +negative errno int fsl_platform_wakeup_disable(struct device *dev) {
> > + return fsl_platform_wakeup_config(dev, false); }
> > +EXPORT_SYMBOL_GPL(fsl_platform_wakeup_disable);
> > +
> > +static int __init fsl_plat_pm_init(void) {
> > + spin_lock_init(&plat_pm.lock);
> > + INIT_LIST_HEAD(&plat_pm.node);
> > + return 0;
> > +}
> > +
> > +core_initcall(fsl_plat_pm_init);
> > diff --git a/include/soc/fsl/plat_pm.h b/include/soc/fsl/plat_pm.h new
> > file mode 100644 index 0000000..bbe151e
> > --- /dev/null
> > +++ b/include/soc/fsl/plat_pm.h
> > @@ -0,0 +1,22 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// plat_pm.h - Freescale platform PM Header // // Copyright 2018 NXP
> > +// // Author: Ran Wang <ran.wang_1@nxp.com>,
> > +
> > +#ifndef __FSL_PLAT_PM_H
> > +#define __FSL_PLAT_PM_H
> > +
> > +typedef int (*fsl_plat_pm_handle)(struct device *dev, bool flag,
> > + void *handle_priv);
> > +
> > +int register_fsl_platform_wakeup_source(fsl_plat_pm_handle handle,
> > + void *handle_priv);
> > +int deregister_fsl_platform_wakeup_source(void *handle_priv); int
> > +fsl_platform_wakeup_config(struct device *dev, bool flag); int
> > +fsl_platform_wakeup_enable(struct device *dev); int
> > +fsl_platform_wakeup_disable(struct device *dev);
> > +
> > +#endif // __FSL_PLAT_PM_H
>=20
^ permalink raw reply
* Re: [RFC PATCH v1 00/17] ban the use of _PAGE_XXX flags outside platform specific code
From: Christophe Leroy @ 2018-09-06 21:36 UTC (permalink / raw)
To: Aneesh Kumar K.V, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, npiggin, aneesh.kumar
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <8736uneylc.fsf@linux.ibm.com>
On 09/06/2018 09:58 AM, Aneesh Kumar K.V wrote:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
>> Today flags like for instance _PAGE_RW or _PAGE_USER are used through
>> common parts of code.
>> Using those directly in common parts of code have proven to lead to
>> mistakes or misbehaviour, because their use is not always as trivial
>> as one could think.
>>
>> For instance, (flags & _PAGE_USER) == 0 isn't enough to tell
>> that a page is a kernel page, because some targets are using
>> _PAGE_PRIVILEDGED and not _PAGE_USER, so the test has to be
>> (flags & (_PAGE_USER | _PAGE_PRIVILEDGED)) == _PAGE_PRIVILEDGED
>> This has to (bad) consequences:
>>
>> - All targets must define every bit, even the unsupported ones,
>> leading to a lot of useless #define _PAGE_XXX 0
>> - If someone forgets to take into account all possible _PAGE_XXX bits
>> for the case, we can get unexpected behaviour on some targets.
>>
>> This becomes even more complex when we come to using _PAGE_RW.
>> Testing (flags & _PAGE_RW) is not enough to test whether a page
>> if writable or not, because:
>>
>> - Some targets have _PAGE_RO instead, which has to be unset to tell
>> a page is writable
>> - Some targets have _PAGE_R and _PAGE_W, in which case
>> _PAGE_RW = _PAGE_R | _PAGE_W
>> - Even knowing whether a page is readable is not always trivial because:
>> - Some targets requires to check that _PAGE_R is set to ensure page
>> is readable
>> - Some targets requires to check that _PAGE_NA is not set
>> - Some targets requires to check that _PAGE_RO or _PAGE_RW is set
>>
>> Etc ....
>>
>> In order to work around all those issues and minimise the risks of errors,
>> this serie aims at removing all use of _PAGE_XXX flags from powerpc code
>> and always use pte_xxx() and pte_mkxxx() accessors instead. Those accessors
>> are then defined in target specific parts of the kernel code.
>
> The series is really good. It also helps in code readability. Few things
> i am not sure there is a way to reduce the overhead
>
> - access = _PAGE_EXEC;
> + access = pte_val(pte_mkexec(__pte(0)));
>
> Considering we have multiple big endian to little endian coversion there
> for book3s 64.
Thanks for the review.
For the above, I propose the following:
diff --git a/arch/powerpc/mm/hash_utils_64.c
b/arch/powerpc/mm/hash_utils_64.c
index f23a89d8e4ce..904ac9c84ea5 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1482,7 +1482,7 @@ static bool should_hash_preload(struct mm_struct
*mm, unsigned long ea)
#endif
void hash_preload(struct mm_struct *mm, unsigned long ea,
- unsigned long access, unsigned long trap)
+ bool is_exec, unsigned long trap)
{
int hugepage_shift;
unsigned long vsid;
@@ -1490,6 +1490,7 @@ void hash_preload(struct mm_struct *mm, unsigned
long ea,
pte_t *ptep;
unsigned long flags;
int rc, ssize, update_flags = 0;
+ unsigned long access = is_exec ? _PAGE_EXEC : 0;
BUG_ON(REGION_ID(ea) != USER_REGION_ID);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 5c8530d0c611..4122f26a2f44 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -507,7 +507,8 @@ void update_mmu_cache(struct vm_area_struct *vma,
unsigned long address,
* We don't need to worry about _PAGE_PRESENT here because we are
* called with either mm->page_table_lock held or ptl lock held
*/
- unsigned long access, trap;
+ unsigned long trap;
+ bool is_exec;
if (radix_enabled()) {
prefetch((void *)address);
@@ -529,10 +530,10 @@ void update_mmu_cache(struct vm_area_struct *vma,
unsigned long address,
trap = current->thread.regs ? TRAP(current->thread.regs) : 0UL;
switch (trap) {
case 0x300:
- access = 0UL;
+ is_exec = false;
break;
case 0x400:
- access = _PAGE_EXEC;
+ is_exec = true;
break;
default:
return;
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index e5d779eed181..dd7f9b951d25 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -82,7 +82,7 @@ static inline void _tlbivax_bcast(unsigned long
address, unsigned int pid,
#else /* CONFIG_PPC_MMU_NOHASH */
extern void hash_preload(struct mm_struct *mm, unsigned long ea,
- unsigned long access, unsigned long trap);
+ bool is_exec, unsigned long trap);
extern void _tlbie(unsigned long address);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index f983ffa24aa0..506e5c3e96da 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -263,7 +263,7 @@ static void __init __mapin_ram_chunk(unsigned long
offset, unsigned long top)
map_kernel_page(v, p, f);
#ifdef CONFIG_PPC_STD_MMU_32
if (ktext)
- hash_preload(&init_mm, v, 0, 0x300);
+ hash_preload(&init_mm, v, false, 0x300);
#endif
v += PAGE_SIZE;
p += PAGE_SIZE;
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index bea6c544e38f..38a793bfca37 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -163,7 +163,7 @@ void __init setbat(int index, unsigned long virt,
phys_addr_t phys,
* Preload a translation in the hash table
*/
void hash_preload(struct mm_struct *mm, unsigned long ea,
- unsigned long access, unsigned long trap)
+ bool is_exec, unsigned long trap)
{
pmd_t *pmd;
>
> Other thing is __ioremap_at where we do
>
> + pte_t pte = __pte(flags);
>
> /* Make sure we have the base flags */
> - if ((flags & _PAGE_PRESENT) == 0)
> + if (!pte_present(pte))
This one is using pte_raw(), so shouldn't be a problem.
Since the function is doing almost nothing of on the flags, maybe
we could just replace the above by pte_present(__pte(flags)) and
leave the rest as is.
>
> - err = map_kernel_page(v+i, p+i, flags);
> + err = map_kernel_page(v + i, p + i, pte_val(pte));
Maybe another alternative would be to pass a pte_t to map_kernel_page(),
then we have to find an optimised way to insert the RPN into it before
calling set_pte_at() instead of using pfn_pte() ?
If we are so concerned by the multiple conversions, should we modify all
the pte_mkxxxx() to use pte_raw() and __pte_raw() instead of pte_val()
and __pte() ?
>
>
> But otherwise for the series.
>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>
Thanks
Christophe
^ permalink raw reply related
* Re: [PATCH v3] powerpc/powernv: Make possible for user to force a full ipl cec reboot
From: Andrew Donnellan @ 2018-09-07 8:20 UTC (permalink / raw)
To: Vaibhav Jain, Benjamin Herrenschmidt, Michael Ellerman,
Stewart Smith
Cc: linuxppc-dev, Vasant Hegde, Michael Neuling, Nicholas Piggin,
Oliver O'Halloran
In-Reply-To: <20180907073448.6908-1-vaibhav@linux.ibm.com>
On 07/09/18 17:34, Vaibhav Jain wrote:
> Ever since fast reboot is enabled by default in opal,
> opal_cec_reboot() will use fast-reset instead of full IPL to perform
> system reboot. This leaves the user with no direct way to force a full
> IPL reboot except changing an nvram setting that persistently disables
> fast-reset for all subsequent reboots.
>
> This patch provides a more direct way for the user to force a one-shot
> full IPL reboot by passing the command line argument 'full' to the
> reboot command. So the user will be able to tweak the reboot behavior
> via:
>
> $ sudo reboot full # Force a full ipl reboot skipping fast-reset
>
> or
> $ sudo reboot # default reboot path (usually fast-reset)
>
> The reboot command passes the un-parsed command argument to the kernel
> via the 'Reboot' syscall which is then passed on to the arch function
> pnv_restart(). The patch updates pnv_restart() to handle this cmd-arg
> and issues opal_cec_reboot2 with OPAL_REBOOT_FULL_IPL to force a full
> IPL reset.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
This looks better!
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> ---
> Change-log:
>
> v3 -> Re-factored the code to make it more readable [Andrew]
> Handle return of OPAL_SUCCESS from cec_reboot variants
> [Vasant]
>
> v2 -> Updated the code to handle case when opal_cec_reboot2() is
> not supported by opal. [Andrew]
>
> -> Force a call to opal_cec_reboot() is opal_cec_reboot2()
> fails or the action verb 'cmd' is not recognized.
> ---
> arch/powerpc/include/asm/opal-api.h | 1 +
> arch/powerpc/platforms/powernv/setup.c | 36 +++++++++++++++++++++-----
> 2 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
> index 8365353330b4..870fb7b239ea 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -1050,6 +1050,7 @@ enum OpalSysCooling {
> enum {
> OPAL_REBOOT_NORMAL = 0,
> OPAL_REBOOT_PLATFORM_ERROR = 1,
> + OPAL_REBOOT_FULL_IPL = 2,
> };
>
> /* Argument to OPAL_PCI_TCE_KILL */
> diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
> index adddde023622..79fd839faa2d 100644
> --- a/arch/powerpc/platforms/powernv/setup.c
> +++ b/arch/powerpc/platforms/powernv/setup.c
> @@ -219,17 +219,41 @@ static void pnv_prepare_going_down(void)
>
> static void __noreturn pnv_restart(char *cmd)
> {
> - long rc = OPAL_BUSY;
> + long rc;
>
> pnv_prepare_going_down();
>
> - while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
> - rc = opal_cec_reboot();
> - if (rc == OPAL_BUSY_EVENT)
> - opal_poll_events(NULL);
> + do {
> + if (!cmd)
> + rc = opal_cec_reboot();
> + else if (strcmp(cmd, "full") == 0)
> + rc = opal_cec_reboot2(OPAL_REBOOT_FULL_IPL, NULL);
> else
> + rc = OPAL_UNSUPPORTED;
> +
> + if (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
> + /* Opal is busy wait for some time and retry */
> + opal_poll_events(NULL);
> mdelay(10);
> - }
> +
> + } else if (cmd && rc) {
> + /* Unknown error while issuing reboot */
> + if (rc == OPAL_UNSUPPORTED)
> + pr_err("Unsupported '%s' reboot.\n", cmd);
> + else
> + pr_err("Unable to issue '%s' reboot. Err=%ld\n",
> + cmd, rc);
> + pr_info("Forcing a cec-reboot\n");
> + cmd = NULL;
> + rc = OPAL_BUSY;
> +
> + } else if (rc != OPAL_SUCCESS) {
> + /* Unknown error while issuing cec-reboot */
> + pr_err("Unable to reboot. Err=%ld\n", rc);
> + }
> +
> + } while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT);
> +
> for (;;)
> opal_poll_events(NULL);
> }
>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH v3] powerpc/powernv: Make possible for user to force a full ipl cec reboot
From: Vaibhav Jain @ 2018-09-07 7:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman, Stewart Smith
Cc: Vaibhav Jain, linuxppc-dev, Andrew Donnellan, Vasant Hegde,
Michael Neuling, Nicholas Piggin, Oliver O'Halloran
Ever since fast reboot is enabled by default in opal,
opal_cec_reboot() will use fast-reset instead of full IPL to perform
system reboot. This leaves the user with no direct way to force a full
IPL reboot except changing an nvram setting that persistently disables
fast-reset for all subsequent reboots.
This patch provides a more direct way for the user to force a one-shot
full IPL reboot by passing the command line argument 'full' to the
reboot command. So the user will be able to tweak the reboot behavior
via:
$ sudo reboot full # Force a full ipl reboot skipping fast-reset
or
$ sudo reboot # default reboot path (usually fast-reset)
The reboot command passes the un-parsed command argument to the kernel
via the 'Reboot' syscall which is then passed on to the arch function
pnv_restart(). The patch updates pnv_restart() to handle this cmd-arg
and issues opal_cec_reboot2 with OPAL_REBOOT_FULL_IPL to force a full
IPL reset.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
Change-log:
v3 -> Re-factored the code to make it more readable [Andrew]
Handle return of OPAL_SUCCESS from cec_reboot variants
[Vasant]
v2 -> Updated the code to handle case when opal_cec_reboot2() is
not supported by opal. [Andrew]
-> Force a call to opal_cec_reboot() is opal_cec_reboot2()
fails or the action verb 'cmd' is not recognized.
---
arch/powerpc/include/asm/opal-api.h | 1 +
arch/powerpc/platforms/powernv/setup.c | 36 +++++++++++++++++++++-----
2 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
index 8365353330b4..870fb7b239ea 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -1050,6 +1050,7 @@ enum OpalSysCooling {
enum {
OPAL_REBOOT_NORMAL = 0,
OPAL_REBOOT_PLATFORM_ERROR = 1,
+ OPAL_REBOOT_FULL_IPL = 2,
};
/* Argument to OPAL_PCI_TCE_KILL */
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index adddde023622..79fd839faa2d 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -219,17 +219,41 @@ static void pnv_prepare_going_down(void)
static void __noreturn pnv_restart(char *cmd)
{
- long rc = OPAL_BUSY;
+ long rc;
pnv_prepare_going_down();
- while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
- rc = opal_cec_reboot();
- if (rc == OPAL_BUSY_EVENT)
- opal_poll_events(NULL);
+ do {
+ if (!cmd)
+ rc = opal_cec_reboot();
+ else if (strcmp(cmd, "full") == 0)
+ rc = opal_cec_reboot2(OPAL_REBOOT_FULL_IPL, NULL);
else
+ rc = OPAL_UNSUPPORTED;
+
+ if (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
+ /* Opal is busy wait for some time and retry */
+ opal_poll_events(NULL);
mdelay(10);
- }
+
+ } else if (cmd && rc) {
+ /* Unknown error while issuing reboot */
+ if (rc == OPAL_UNSUPPORTED)
+ pr_err("Unsupported '%s' reboot.\n", cmd);
+ else
+ pr_err("Unable to issue '%s' reboot. Err=%ld\n",
+ cmd, rc);
+ pr_info("Forcing a cec-reboot\n");
+ cmd = NULL;
+ rc = OPAL_BUSY;
+
+ } else if (rc != OPAL_SUCCESS) {
+ /* Unknown error while issuing cec-reboot */
+ pr_err("Unable to reboot. Err=%ld\n", rc);
+ }
+
+ } while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT);
+
for (;;)
opal_poll_events(NULL);
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/
From: Greg Kroah-Hartman @ 2018-09-07 7:21 UTC (permalink / raw)
To: Daniel Vetter
Cc: Steven Rostedt, Jonathan Corbet, Mark Rutland,
Linux MIPS Mailing List, Linux Fbdev development list, X86 ML,
kvm, Linux Doc Mailing List, Peter Zijlstra, James Hogan,
Henrik Austad, Will Deacon, dri-devel, Masahiro Yamada,
Jan Kandziora, Paul Mackerras, Henrik Austad, Pavel Machek,
H. Peter Anvin, Evgeniy Polyakov, linux-s390, Ian Kent,
linux-security-module, Paul Moore, Michael Ellerman, Helge Deller,
Radim Krčmář, James E.J. Bottomley, Ingo Molnar,
Paul E. McKenney, Len Brown, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Lai Jiangshan, Jiri Slaby,
Josh Triplett, linux-gpio, Rob Herring, Mathieu Desnoyers,
Jacek Anaszewski, Bjorn Helgaas, Thomas Gleixner, linux-kbuild,
Jens Axboe, Karsten Keil, Michal Marek, linux-parisc,
Heiko Carstens, linux-ide, Linux PCI, Linux PM list,
Rafael J. Wysocki, Linux Kernel Mailing List, Ralf Baechle,
linux-spi, Paul Burton, Mark Brown, netdev, Martin Schwidefsky,
Paolo Bonzini, Andrew Morton, linuxppc-dev, David S. Miller,
devicetree
In-Reply-To: <CAKMK7uHoeB89-VVS8qVaoNiP_0waHHJ=dFCUgXkRDTnRkXz69g@mail.gmail.com>
On Thu, Sep 06, 2018 at 11:39:42PM +0200, Daniel Vetter wrote:
> On Thu, Sep 6, 2018 at 6:01 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Thu, 6 Sep 2018 09:58:04 -0600
> > Jonathan Corbet <corbet@lwn.net> wrote:
> >
> >> Thanks,
> >>
> >> jon (who is increasingly inclined to apply this patch)
> >
> > As Colin Kaepernick now says... "Just do it!"
> >
> > ;-)
>
> +1
>
> But I'm biased, I'm part of the party that is responsible for the new
> shiny documentation system ...
I am not responsible for any of the new shiny documentation system, and
I think this is a good idea:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules
From: Ley Foon Tan @ 2018-09-07 2:08 UTC (permalink / raw)
To: Rob Herring, devicetree, linux-kernel, Masahiro Yamada
Cc: Michal Marek, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Yoshinori Sato, Michal Simek, Ralf Baechle,
Paul Burton, James Hogan, Ley Foon Tan, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Chris Zankel, Max Filippov,
linux-kbuild, linux-snps-arc, linux-arm-kernel, uclinux-h8-devel,
linux-mips, nios2-dev, linuxppc-dev, linux-xtensa
In-Reply-To: <20180905235327.5996-7-robh@kernel.org>
On Wed, 2018-09-05 at 18:53 -0500, Rob Herring wrote:
> There is nothing arch specific about building dtb files other than
> their
> location under /arch/*/boot/dts/. Keeping each arch aligned is a
> pain.
> The dependencies and supported targets are all slightly different.
> Also, a cross-compiler for each arch is needed, but really the host
> compiler preprocessor is perfectly fine for building dtbs. Move the
> build rules to a common location and remove the arch specific ones.
> This
> is done in a single step to avoid warnings about overriding rules.
>=20
> The build dependencies had been a mixture of 'scripts' and/or
> 'prepare'.
> These pull in several dependencies some of which need a target
> compiler
> (specifically devicetable-offsets.h) and aren't needed to build dtbs.
> All that is really needed is dtc, so adjust the dependencies to only
> be
> dtc.
>=20
> This change enables support 'dtbs_install' on some arches which were
> missing the target.
>=20
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Michal Marek <michal.lkml@markovi.net>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Michal Simek <monstr@monstr.eu>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Paul Burton <paul.burton@mips.com>
> Cc: James Hogan <jhogan@kernel.org>
> Cc: Ley Foon Tan <lftan@altera.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Cc: linux-kbuild@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: uclinux-h8-devel@lists.sourceforge.jp
> Cc: linux-mips@linux-mips.org
> Cc: nios2-dev@lists.rocketboards.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-xtensa@linux-xtensa.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Please ack so I can take the whole series via the DT tree.
>=20
For nios2:
Acked-by: Ley Foon Tan <ley.foon.tan@intel.com>
Regards
Ley Foon
^ permalink raw reply
* Re: [RFC 0/4] Virtio uses DMA API for all devices
From: Jiandi An @ 2018-09-07 0:09 UTC (permalink / raw)
To: Christoph Hellwig, Benjamin Herrenschmidt
Cc: Michael S. Tsirkin, Will Deacon, Anshuman Khandual,
virtualization, linux-kernel, linuxppc-dev, aik, robh, joe,
elfring, david, jasowang, mpe, linuxram, haren, paulus, srikar,
robin.murphy, jean-philippe.brucker, marc.zyngier,
thomas.lendacky, brijesh.singh, jiandi.an
In-Reply-To: <20180809054013.GA20507@infradead.org>
On 08/09/2018 12:40 AM, Christoph Hellwig wrote:
> On Thu, Aug 09, 2018 at 08:13:32AM +1000, Benjamin Herrenschmidt wrote:
>>>> - if (xen_domain())
>>>> + if (xen_domain() || pseries_secure_vm())
>>>> return true;
>>>
>>> I don't think it's pseries specific actually. E.g. I suspect AMD SEV
>>> might benefit from the same kind of hack.
>>
>> As long as they can provide the same guarantee that the DMA ops are
>> completely equivalent between virtio and other PCI devices, at least on
>> the same bus, ie, we don't have to go hack special DMA ops.
>>
>> I think the latter is really what Christoph wants to avoid for good
>> reasons.
>
> Yes. I also generally want to avoid too much arch specific magic.
>
> FYI, I'm off to a week-long vacation today, don't expect quick replies.
>
>
>
I've been following this RFC series as this has impact on AMD SEV.
Could you guys keep us in the loop on this (thomas.lendacky@amd.com,
brijesh.singh@amd.com, jiandi.an@amd.com are on cc).
AMD SEV today sets swiotlb_force to SWIOTLB_FORCE early on in
x86_64_start_kernel. During start_kernel, mem_encrypt_init() sets
dma_ops to swiotlb_dma_ops if SEV is on as it uses SWIOTLB to bounce
buffer DMA operation and it's marked as decrypted.
For virtio device we have to pass in iommu_platform=true flag for
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.
Anshuman's patch [RFC,2/4] virtio: Override device's DMA OPS with
virtio_direct_dma_ops selectively sets the default dma ops of
virtio device's parent pci to direct_dma_ops if VIRTIO_F_IOMMU_PLATFORM
is set. And later platform specific code can override the dma ops again.
int virtio_finalize_features(struct virtio_device *dev)
{
int ret = dev->config->finalize_features(dev);
@@ -174,6 +176,9 @@ int virtio_finalize_features(struct virtio_device *dev)
if (ret)
return ret;
+ if (virtio_has_iommu_quirk(dev))
+ set_dma_ops(dev->dev.parent, &virtio_direct_dma_ops);
+
if (!virtio_has_feature(dev, VIRTIO_F_VERSION_1))
return 0;
Would like to be in the loop and put in the platform specific code for
AMD SEV at the same time along with this. Or does it make sense that if
swiotlb force is set don't override virtio device's parent dma_ops to
direct_dma_ops? What if someone passes in swiotlb=force from kernel
boot command line parameter, this would override the parent pci device's
dma ops to direct_dma_ops.
So where is this RFC standing currently. I saw Michael's comment mentioning
this RFC is blocked by its performance overhead for now for switching to
using DMA ops unconditionally.
-Jiandi
^ permalink raw reply
* Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/
From: Daniel Vetter @ 2018-09-06 21:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jonathan Corbet, Mark Rutland, Linux MIPS Mailing List,
Linux Fbdev development list, X86 ML, kvm, Linux Doc Mailing List,
Peter Zijlstra, James Hogan, Henrik Austad, Will Deacon,
dri-devel, Masahiro Yamada, Jan Kandziora, Paul Mackerras,
Henrik Austad, Pavel Machek, H. Peter Anvin, Evgeniy Polyakov,
linux-s390, Ian Kent, linux-security-module, Paul Moore,
Michael Ellerman, Helge Deller, Radim Krčmář,
James E.J. Bottomley, Ingo Molnar, Paul E. McKenney, Len Brown,
Mike Rapoport, Bartlomiej Zolnierkiewicz, Lai Jiangshan,
Jiri Slaby, Josh Triplett, linux-gpio, Rob Herring,
Mathieu Desnoyers, Jacek Anaszewski, Bjorn Helgaas,
Thomas Gleixner, linux-kbuild, Jens Axboe, Karsten Keil,
Michal Marek, linux-parisc, Heiko Carstens, linux-ide, Linux PCI,
Greg Kroah-Hartman, Linux PM list, Rafael J. Wysocki,
Linux Kernel Mailing List, Ralf Baechle, linux-spi, Paul Burton,
Mark Brown, netdev, Martin Schwidefsky, Paolo Bonzini,
Andrew Morton, linuxppc-dev, David S. Miller, devicetree
In-Reply-To: <20180906120120.3dd1fc91@gandalf.local.home>
On Thu, Sep 6, 2018 at 6:01 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 6 Sep 2018 09:58:04 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
>
>> Thanks,
>>
>> jon (who is increasingly inclined to apply this patch)
>
> As Colin Kaepernick now says... "Just do it!"
>
> ;-)
+1
But I'm biased, I'm part of the party that is responsible for the new
shiny documentation system ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add maintainer entries for RPA pci hotplug drivers
From: Bjorn Helgaas @ 2018-09-06 19:17 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: mpe, benh, linuxppc-dev, nfont, linux-pci, bhelgaas, linux-kernel
In-Reply-To: <1534814431-20112-1-git-send-email-tyreld@linux.vnet.ibm.com>
On Mon, Aug 20, 2018 at 06:20:31PM -0700, Tyrel Datwyler wrote:
> Adding myself as maintiner of the IBM RPA hotplug modules located in
> drivers/pci/hotplug directory. These modules provide kernel interfaces
> for support of Dynamic Logical Partitioning (DLPAR) of Logical and
> Physical IO slots, and hotplug of physical PCI slots of a PHB on
> RPA-compliant ppc64 platforms (pseries).
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Applied to for-linus for v4.19, thanks!
> ---
> MAINTAINERS | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5df1b36..7b5dc3f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6984,6 +6984,20 @@ F: drivers/crypto/vmx/aes*
> F: drivers/crypto/vmx/ghash*
> F: drivers/crypto/vmx/ppc-xlate.pl
>
> +IBM Power PCI Hotplug Driver for RPA-compliant PPC64 platform
> +M: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> +L: linux-pci@vger.kernel.org
> +L: linuxppc-dev@lists.ozlabs.org
> +S: Supported
> +F: drivers/pci/hotplug/rpaphp*
> +
> +IBM Power IO DLPAR Driver for RPA-compliant PPC64 platform
> +M: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> +L: linux-pci@vger.kernel.org
> +L: linuxppc-dev@lists.ozlabs.org
> +S: Supported
> +F: drivers/pci/hotplug/rpadlpar*
> +
> IBM ServeRAID RAID DRIVER
> S: Orphan
> F: drivers/scsi/ips.*
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules
From: Paul Burton @ 2018-09-06 17:11 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-kernel, Masahiro Yamada, Michal Marek,
Vineet Gupta, Russell King, Catalin Marinas, Will Deacon,
Yoshinori Sato, Michal Simek, Ralf Baechle, James Hogan,
Ley Foon Tan, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Chris Zankel, Max Filippov, linux-kbuild,
linux-snps-arc, linux-arm-kernel, uclinux-h8-devel, linux-mips,
nios2-dev, linuxppc-dev, linux-xtensa
In-Reply-To: <20180905235327.5996-7-robh@kernel.org>
Hi Rob,
On Wed, Sep 05, 2018 at 06:53:24PM -0500, Rob Herring wrote:
> There is nothing arch specific about building dtb files other than their
> location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
> The dependencies and supported targets are all slightly different.
> Also, a cross-compiler for each arch is needed, but really the host
> compiler preprocessor is perfectly fine for building dtbs. Move the
> build rules to a common location and remove the arch specific ones. This
> is done in a single step to avoid warnings about overriding rules.
>
> The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
> These pull in several dependencies some of which need a target compiler
> (specifically devicetable-offsets.h) and aren't needed to build dtbs.
> All that is really needed is dtc, so adjust the dependencies to only be
> dtc.
>
> This change enables support 'dtbs_install' on some arches which were
> missing the target.
>
>%
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Please ack so I can take the whole series via the DT tree.
For MIPS:
Acked-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
^ permalink raw reply
* Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/
From: Steven Rostedt @ 2018-09-06 16:01 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Pavel Machek, Henrik Austad, linux-doc, Bjorn Helgaas,
Paul E. McKenney, Josh Triplett, Mathieu Desnoyers, Lai Jiangshan,
Jens Axboe, Rob Herring, Mark Rutland, Bartlomiej Zolnierkiewicz,
Linus Walleij, David S. Miller, Karsten Keil, Masahiro Yamada,
Michal Marek, Peter Zijlstra, Ingo Molnar, Will Deacon,
Ralf Baechle, Paul Burton, James Hogan, Paul Moore,
James E.J. Bottomley, Helge Deller, Rafael J. Wysocki, Len Brown,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Martin Schwidefsky, Heiko Carstens, Greg Kroah-Hartman,
Jiri Slaby, Mark Brown, Thomas Gleixner, Paolo Bonzini,
Radim Krčmář, Evgeniy Polyakov, H. Peter Anvin,
x86, Andrew Morton, Ian Kent, Jacek Anaszewski, Mike Rapoport,
Jan Kandziora, linux-kernel, linux-pci, devicetree, dri-devel,
linux-fbdev, linux-gpio, linux-ide, netdev, linux-kbuild,
linux-mips, linux-security-module, linux-parisc, linux-pm,
linuxppc-dev, linux-s390, linux-spi, kvm, Henrik Austad
In-Reply-To: <20180906095804.5ab2716f@lwn.net>
On Thu, 6 Sep 2018 09:58:04 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> Thanks,
>
> jon (who is increasingly inclined to apply this patch)
As Colin Kaepernick now says... "Just do it!"
;-)
-- Steve
^ permalink raw reply
* Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/
From: Jonathan Corbet @ 2018-09-06 15:58 UTC (permalink / raw)
To: Steven Rostedt
Cc: Pavel Machek, Henrik Austad, linux-doc, Bjorn Helgaas,
Paul E. McKenney, Josh Triplett, Mathieu Desnoyers, Lai Jiangshan,
Jens Axboe, Rob Herring, Mark Rutland, Bartlomiej Zolnierkiewicz,
Linus Walleij, David S. Miller, Karsten Keil, Masahiro Yamada,
Michal Marek, Peter Zijlstra, Ingo Molnar, Will Deacon,
Ralf Baechle, Paul Burton, James Hogan, Paul Moore,
James E.J. Bottomley, Helge Deller, Rafael J. Wysocki, Len Brown,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Martin Schwidefsky, Heiko Carstens, Greg Kroah-Hartman,
Jiri Slaby, Mark Brown, Thomas Gleixner, Paolo Bonzini,
Radim Krčmář, Evgeniy Polyakov, H. Peter Anvin,
x86, Andrew Morton, Ian Kent, Jacek Anaszewski, Mike Rapoport,
Jan Kandziora, linux-kernel, linux-pci, devicetree, dri-devel,
linux-fbdev, linux-gpio, linux-ide, netdev, linux-kbuild,
linux-mips, linux-security-module, linux-parisc, linux-pm,
linuxppc-dev, linux-s390, linux-spi, kvm, Henrik Austad
In-Reply-To: <20180904095908.13298b3d@gandalf.local.home>
On Tue, 4 Sep 2018 09:59:08 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 4 Sep 2018 13:30:30 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
>
> > I'd say this is still quite valueable, and it might be worth fixing,
> > rather then removing completely.
>
> I agree. Perhaps we should have a 00-DESCRIPTION file in each
> directory, and each file could start with a:
>
> DESCRIPTION: <one line description here>
>
> and then these files could be generated by those that have these tags.
I really don't want to hack up yet another documentation syntax and
processing scheme. We already have one that does all of this and more.
That energy would be far better spent bringing the docs into the RST
hierarchy, IMO.
Thanks,
jon (who is increasingly inclined to apply this patch)
^ permalink raw reply
* Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
From: Michal Hocko @ 2018-09-06 13:46 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rob Herring, linux-mm, Andrew Morton, davem, Greg Kroah-Hartman,
mingo, Michael Ellerman, paul.burton, Thomas Gleixner, tony.luck,
linux-ia64, linux-mips, linuxppc-dev, sparclinux,
Linux Kernel Mailing List
In-Reply-To: <20180906133958.GM27492@rapoport-lnx>
On Thu 06-09-18 16:39:58, Mike Rapoport wrote:
> On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote:
> > On Thu 06-09-18 15:43:21, Mike Rapoport wrote:
> > > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote:
> > > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote:
> > > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote:
> > > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> > > > > > >
> > > > > > > The conversion is done using
> > > > > > >
> > > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \
> > > > > > > $(git grep -l memblock_virt_alloc)
> > > > > >
> > > > > > What's the reason to do this? It seems like a lot of churn even if a
> > > > > > mechanical change.
> > > > >
> > > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g:
> > > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic.
> > > > >
> > > > > And for consistency I've changed the memblock_virt_alloc as well.
> > > >
> > > > I would keep the current API unless the name is terribly misleading or
> > > > it can be improved a lot. Neither seems to be the case here. So I would
> > > > rather stick with the status quo.
> > >
> > > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in
> > > 'memblock_virt_alloc_try_nid_nopanic' and 'memblock_virt_alloc_low_nopanic'
> > > reduces code readability in my opinion.
> >
> > Well, is _nopanic really really useful in the name. Do we even need/want
> > implicit panic/nopanic semantic? The code should rather check for the
> > return value and decide depending on the code path. I suspect removing
> > panic/nopanic would make the API slightly lighter.
>
> I agree that panic/nopanic should be removed. But I prefer to start with
> equivalent replacement to make it as automated as possible and update
> memblock API when the dust settles a bit.
Yes, I agree with that approach. But that also doesn't justify the
renaming
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH 07/29] memblock: remove _virt from APIs returning virtual address
From: Mike Rapoport @ 2018-09-06 13:39 UTC (permalink / raw)
To: Michal Hocko
Cc: Rob Herring, linux-mm, Andrew Morton, davem, Greg Kroah-Hartman,
mingo, Michael Ellerman, paul.burton, Thomas Gleixner, tony.luck,
linux-ia64, linux-mips, linuxppc-dev, sparclinux,
Linux Kernel Mailing List
In-Reply-To: <20180906130102.GY14951@dhcp22.suse.cz>
On Thu, Sep 06, 2018 at 03:01:02PM +0200, Michal Hocko wrote:
> On Thu 06-09-18 15:43:21, Mike Rapoport wrote:
> > On Thu, Sep 06, 2018 at 09:28:00AM +0200, Michal Hocko wrote:
> > > On Wed 05-09-18 20:20:18, Mike Rapoport wrote:
> > > > On Wed, Sep 05, 2018 at 12:04:36PM -0500, Rob Herring wrote:
> > > > > On Wed, Sep 5, 2018 at 11:00 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> > > > > >
> > > > > > The conversion is done using
> > > > > >
> > > > > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \
> > > > > > $(git grep -l memblock_virt_alloc)
> > > > >
> > > > > What's the reason to do this? It seems like a lot of churn even if a
> > > > > mechanical change.
> > > >
> > > > I felt that memblock_virt_alloc_ is too long for a prefix, e.g:
> > > > memblock_virt_alloc_node_nopanic, memblock_virt_alloc_low_nopanic.
> > > >
> > > > And for consistency I've changed the memblock_virt_alloc as well.
> > >
> > > I would keep the current API unless the name is terribly misleading or
> > > it can be improved a lot. Neither seems to be the case here. So I would
> > > rather stick with the status quo.
> >
> > I'm ok with the memblock_virt_alloc by itself, but having 'virt' in
> > 'memblock_virt_alloc_try_nid_nopanic' and 'memblock_virt_alloc_low_nopanic'
> > reduces code readability in my opinion.
>
> Well, is _nopanic really really useful in the name. Do we even need/want
> implicit panic/nopanic semantic? The code should rather check for the
> return value and decide depending on the code path. I suspect removing
> panic/nopanic would make the API slightly lighter.
I agree that panic/nopanic should be removed. But I prefer to start with
equivalent replacement to make it as automated as possible and update
memblock API when the dust settles a bit.
> --
> Michal Hocko
> SUSE Labs
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [RFC PATCH V2 1/4] mm: Export alloc_migrate_huge_page
From: Aneesh Kumar K.V @ 2018-09-06 13:32 UTC (permalink / raw)
To: Michal Hocko
Cc: akpm, Alexey Kardashevskiy, mpe, linux-mm, linux-kernel,
linuxppc-dev
In-Reply-To: <20180906123539.GV14951@dhcp22.suse.cz>
On 09/06/2018 06:05 PM, Michal Hocko wrote:
> On Thu 06-09-18 14:31:11, Michal Hocko wrote:
>> On Thu 06-09-18 11:13:39, Aneesh Kumar K.V wrote:
>>> We want to use this to support customized huge page migration.
>>
>> Please be much more specific. Ideally including the user. Btw. why do
>> you want to skip the hugetlb pools? In other words alloc_huge_page_node*
>> which are intended to an external use?
>
> Ups, I have now found http://lkml.kernel.org/r/20180906054342.25094-2-aneesh.kumar@linux.ibm.com
> which ended up in a different email folder so I have missed it. It would
> be much better to merge those two to make the user immediately obvious.
> There is a good reason to keep newly added functions closer to their
> users.
>
It is the same series. I will fold the patch 1 and 2.
-aneesh
^ permalink raw reply
* Re: [RFC PATCH V2 4/4] powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_get
From: Aneesh Kumar K.V @ 2018-09-06 13:30 UTC (permalink / raw)
To: Michal Hocko
Cc: akpm, Alexey Kardashevskiy, mpe, linux-mm, linux-kernel,
linuxppc-dev
In-Reply-To: <20180906125356.GX14951@dhcp22.suse.cz>
On 09/06/2018 06:23 PM, Michal Hocko wrote:
> On Thu 06-09-18 11:13:42, Aneesh Kumar K.V wrote:
>> Current code doesn't do page migration if the page allocated is a compound page.
>> With HugeTLB migration support, we can end up allocating hugetlb pages from
>> CMA region. Also THP pages can be allocated from CMA region. This patch updates
>> the code to handle compound pages correctly.
>>
>> This use the new helper get_user_pages_cma_migrate. It does one get_user_pages
>> with right count, instead of doing one get_user_pages per page. That avoids
>> reading page table multiple times.
>>
>> The patch also convert the hpas member of mm_iommu_table_group_mem_t to a union.
>> We use the same storage location to store pointers to struct page. We cannot
>> update alll the code path use struct page *, because we access hpas in real mode
>> and we can't do that struct page * to pfn conversion in real mode.
>
> I am not fmailiar with this code so bear with me. I am completely
> missing the purpose of this patch. The changelog doesn't really explain
> that AFAICS. I can only guess that you do not want to establish long
> pins on CMA pages, right? So whenever you are about to pin a page that
> is in CMA you migrate it away to a different !__GFP_MOVABLE page, right?
That is right.
> If that is the case then how do you handle pins which are already in
> zone_movable? I do not see any specific check for those.
>
> Btw. why is this a proper thing to do? Problems with longterm pins are
> not only for CMA/ZONE_MOVABLE pages. Pinned pages are not reclaimable as
> well so there is a risk of OOMs if there are too many of them. We have
> discussed approaches that would allow to force pin invalidation/revocation
> at LSF/MM. Isn't that a more appropriate solution to the problem you are
> seeing?
>
The CMA area is used on powerpc platforms to allocate guest specific
page table (hash page table). If we don't have sufficient free pages we
fail to allocate hash page table that result in failure to start guest.
Now with vfio, we end up pinning the entire guest RAM. There is a
possibility that these guest RAM pages got allocated from CMA region.
We already do supporting migrating those pages out except for compound
pages. What this patch does is to start supporting compound page
migration that got allocated out of CMA region (ie, THP pages and
hugetlb pages if platform supported hugetlb migration).
Now to do that I added a helper get_user_pages_cma_migrate().
I agree that long term pinned pages do have other issues. The patchset
is not solving that issue.
-aneesh
^ permalink raw reply
* Re: [RFC PATCH 00/29] mm: remove bootmem allocator
From: Mike Rapoport @ 2018-09-06 13:30 UTC (permalink / raw)
To: Greentime Hu
Cc: linux-mm, Andrew Morton, David Miller, gregkh, mingo, mpe, mhocko,
paul.burton, Thomas Gleixner, tony.luck, linux-ia64, linux-mips,
linuxppc-dev, sparclinux, Linux Kernel Mailing List
In-Reply-To: <CAEbi=3dKL1zOYc0DC3yXm=7srw6tUfx-JR=o9n4pVrGp+Sosug@mail.gmail.com>
On Thu, Sep 06, 2018 at 10:33:48AM +0800, Greentime Hu wrote:
> Mike Rapoport <rppt@linux.vnet.ibm.com> 於 2018年9月6日 週四 上午12:04寫道：
> >
> > Hi,
> >
> > These patches switch early memory managment to use memblock directly
> > without any bootmem compatibility wrappers. As the result both bootmem and
> > nobootmem are removed.
> >
> > There are still a couple of things to sort out, the most important is the
> > removal of bootmem usage in MIPS.
> >
> > Still, IMHO, the series is in sufficient state to post and get the early
> > feedback.
> >
> > The patches are build-tested with defconfig for most architectures (I
> > couldn't find a compiler for nds32 and unicore32) and boot-tested on x86
> > VM.
> >
> Hi Mike,
>
> There are nds32 toolchains.
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-nds32le-linux.tar.gz
> https://github.com/vincentzwc/prebuilt-nds32-toolchain/releases/download/20180521/nds32le-linux-glibc-v3-upstream.tar.gz
Thanks!
> Sorry, we have no qemu yet.
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [RFC PATCH V2 2/4] mm: Add get_user_pages_cma_migrate
From: Aneesh Kumar K.V @ 2018-09-06 13:23 UTC (permalink / raw)
To: Michal Hocko
Cc: akpm, Alexey Kardashevskiy, mpe, linux-mm, linux-kernel,
linuxppc-dev
In-Reply-To: <20180906124504.GW14951@dhcp22.suse.cz>
On 09/06/2018 06:15 PM, Michal Hocko wrote:
> On Thu 06-09-18 11:13:40, Aneesh Kumar K.V wrote:
>> This helper does a get_user_pages_fast and if it find pages in the CMA area
>> it will try to migrate them before taking page reference. This makes sure that
>> we don't keep non-movable pages (due to page reference count) in the CMA area.
>> Not able to move pages out of CMA area result in CMA allocation failures.
>
> Again, there is no user so it is hard to guess the intention completely.
> There is no documentation to describe the expected context and
> assumptions about locking etc.
>
patch 4 is the user for the new helper. I will add the documentation
update.
> As noted in the previous email. You should better describe why you are
> bypassing hugetlb pools. I assume that the reason is to guarantee a
> forward progress because those might be sitting in the CMA pools
> already, right?
>
The reason for that is explained in the code
+ struct hstate *h = page_hstate(page);
+ /*
+ * We don't want to dequeue from the pool because pool pages will
+ * mostly be from the CMA region.
+ */
+ return alloc_migrate_huge_page(h, gfp_mask, nid, NULL);
-aneesh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox