* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Bharat Bhushan @ 2013-11-06 5:25 UTC (permalink / raw)
To: Dongsheng Wang, Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259010BC83B@039-SN2MPN1-021.039d.mgd.msft.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV2FuZyBEb25nc2hlbmct
QjQwNTM0DQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA1LCAyMDEzIDg6NDAgQU0NCj4gVG86
IFdvb2QgU2NvdHQtQjA3NDIxDQo+IENjOiBCaHVzaGFuIEJoYXJhdC1SNjU3Nzc7IGxpbnV4cHBj
LWRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggdjUgNC80XSBwb3dl
cnBjLzg1eHg6IGFkZCBzeXNmcyBmb3IgcHcyMCBzdGF0ZSBhbmQgYWx0aXZlYw0KPiBpZGxlDQo+
IA0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBXb29k
IFNjb3R0LUIwNzQyMQ0KPiA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA1LCAyMDEzIDU6NTIg
QU0NCj4gPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0DQo+ID4gQ2M6IFdvb2QgU2NvdHQtQjA3
NDIxOyBCaHVzaGFuIEJoYXJhdC1SNjU3Nzc7IGxpbnV4cHBjLQ0KPiA+IGRldkBsaXN0cy5vemxh
YnMub3JnDQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSCB2NSA0LzRdIHBvd2VycGMvODV4eDogYWRk
IHN5c2ZzIGZvciBwdzIwIHN0YXRlIGFuZA0KPiA+IGFsdGl2ZWMgaWRsZQ0KPiA+DQo+ID4gT24g
U3VuLCAyMDEzLTExLTAzIGF0IDIyOjA0IC0wNjAwLCBXYW5nIERvbmdzaGVuZy1CNDA1MzQgd3Jv
dGU6DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IFdh
bmcgRG9uZ3NoZW5nLUI0MDUzNA0KPiA+ID4gPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMjEsIDIw
MTMgMTE6MTEgQU0NCj4gPiA+ID4gVG86IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+IENjOiBC
aHVzaGFuIEJoYXJhdC1SNjU3Nzc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4g
PiA+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggdjUgNC80XSBwb3dlcnBjLzg1eHg6IGFkZCBzeXNmcyBm
b3IgcHcyMCBzdGF0ZQ0KPiA+ID4gPiBhbmQgYWx0aXZlYyBpZGxlDQo+ID4gPiA+DQo+ID4gPiA+
DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g
PiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gPiA+IFNlbnQ6IFNhdHVyZGF5LCBPY3Rv
YmVyIDE5LCAyMDEzIDM6MjIgQU0NCj4gPiA+ID4gPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0
DQo+ID4gPiA+ID4gQ2M6IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgV29vZCBTY290dC1CMDc0MjE7
IGxpbnV4cHBjLQ0KPiA+ID4gPiA+IGRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4gPiA+ID4gU3Vi
amVjdDogUmU6IFtQQVRDSCB2NSA0LzRdIHBvd2VycGMvODV4eDogYWRkIHN5c2ZzIGZvciBwdzIw
DQo+ID4gPiA+ID4gc3RhdGUgYW5kIGFsdGl2ZWMgaWRsZQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g
T24gVGh1LCAyMDEzLTEwLTE3IGF0IDIyOjAyIC0wNTAwLCBXYW5nIERvbmdzaGVuZy1CNDA1MzQg
d3JvdGU6DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiA+ID4gPiA+ID4gPiBGcm9tOiBCaHVzaGFuIEJoYXJhdC1SNjU3NzcNCj4gPiA+ID4g
PiA+ID4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTMgMjo0NiBQTQ0KPiA+ID4gPiA+
ID4gPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0OyBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4g
PiA+ID4gPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gPiA+ID4gPiA+ID4g
U3ViamVjdDogUkU6IFtQQVRDSCB2NSA0LzRdIHBvd2VycGMvODV4eDogYWRkIHN5c2ZzIGZvciBw
dzIwDQo+ID4gPiA+ID4gPiA+IHN0YXRlIGFuZCBhbHRpdmVjIGlkbGUNCj4gPiA+ID4gPiA+ID4N
Cj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gRnJvbTogV2FuZyBEb25n
c2hlbmctQjQwNTM0DQo+ID4gPiA+ID4gPiA+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVy
IDE3LCAyMDEzIDExOjIyIEFNDQo+ID4gPiA+ID4gPiA+ID4gPiA+IFRvOiBCaHVzaGFuIEJoYXJh
dC1SNjU3Nzc7IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gPiA+ID4gPiA+IENjOiBsaW51
eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+ID4gPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBS
RTogW1BBVENIIHY1IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMNCj4gPiA+ID4gPiA+ID4g
PiA+ID4gZm9yDQo+ID4gPiA+ID4gPiA+ID4gPiA+IHB3MjAgc3RhdGUgYW5kIGFsdGl2ZWMgaWRs
ZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g
PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gRnJvbTogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTMgMTE6MjAg
QU0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0OyBXb29k
IFNjb3R0LUIwNzQyMQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+IENjOiBsaW51eHBwYy1kZXZAbGlz
dHMub3psYWJzLm9yZw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJFOiBbUEFUQ0gg
djUgNC80XSBwb3dlcnBjLzg1eHg6IGFkZCBzeXNmcw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+IGZv
cg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHB3MjAgc3RhdGUgYW5kIGFsdGl2ZWMgaWRsZQ0KPiA+
ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g
PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IEZyb206IFdhbmcgRG9uZ3NoZW5nLUI0MDUzNA0K
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTMg
ODoxNiBBTQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3
NzsgV29vZCBTY290dC1CMDc0MjENCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IENjOiBsaW51eHBw
Yy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gU3ViamVjdDog
UkU6IFtQQVRDSCB2NSA0LzRdIHBvd2VycGMvODV4eDogYWRkDQo+ID4gPiA+ID4gPiA+ID4gPiA+
ID4gPiBzeXNmcyBmb3INCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHB3MjAgc3RhdGUgYW5kIGFs
dGl2ZWMgaWRsZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBGcm9t
OiBCaHVzaGFuIEJoYXJhdC1SNjU3NzcNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gU2VudDog
VGh1cnNkYXksIE9jdG9iZXIgMTcsIDIwMTMgMTowMSBBTQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ID4gPiBUbzogV2FuZyBEb25nc2hlbmctQjQwNTM0OyBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gU3ViamVjdDogUkU6IFtQQVRDSCB2NSA0LzRdIHBvd2Vy
cGMvODV4eDogYWRkDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHN5c2ZzIGZvcg0KPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gPiBwdzIwIHN0YXRlIGFuZCBhbHRpdmVjIGlkbGUNCj4gPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IEZyb206IFdhbmcgRG9u
Z3NoZW5nLUI0MDUzNA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IFNlbnQ6IFR1ZXNkYXks
IE9jdG9iZXIgMTUsIDIwMTMgMjo1MSBQTQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IFRv
OiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IENjOiBCaHVz
aGFuIEJoYXJhdC1SNjU3Nzc7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gbGludXhwcGMt
ZGV2QGxpc3RzLm96bGFicy5vcmc7IFdhbmcNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gRG9u
Z3NoZW5nLUI0MDUzNA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFtQQVRD
SCB2NSA0LzRdIHBvd2VycGMvODV4eDogYWRkDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
c3lzZnMgZm9yDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gcHcyMCBzdGF0ZSBhbmQNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gYWx0aXZlYyBpZGxlDQo+ID4gPiA+ID4gPiA+ID4gPiA+
ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBGcm9tOiBXYW5nIERvbmdzaGVu
Zw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IDxkb25nc2hlbmcud2FuZ0BmcmVlc2NhbGUu
Y29tPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gQWRkIGEgc3lzIGludGVyZmFjZSB0byBlbmFibGUvZGlhYmxlIHB3MjANCj4gPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gPiBzdGF0ZSBvciBhbHRpdmVjIGlkbGUsIGFuZA0KPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiBjb250cm9sIHRoZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+
IHdhaXQgZW50cnkgdGltZS4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiA+IEVuYWJsZS9EaXNhYmxlIGludGVyZmFjZToNCj4gPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiAwLCBkaXNhYmxlLiAxLCBlbmFibGUuDQo+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gL3N5cy9kZXZpY2VzL3N5c3RlbS9jcHUvY3B1WC9wdzIwX3N0YXRlDQo+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gL3N5cy9kZXZpY2VzL3N5c3RlbS9jcHUvY3B1WC9hbHRp
dmVjX2lkbGUNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+IFNldCB3YWl0IHRpbWUgaW50ZXJmYWNlOihOYW5vc2Vjb25kKQ0KPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiA+IC9zeXMvZGV2aWNlcy9zeXN0ZW0vY3B1L2NwdVgvcHcyMF93YWl0
X3RpbWUNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiAvc3lzL2RldmljZXMvc3lzdGVtL2Nw
dS9jcHVYL2FsdGl2ZWNfaWRsZV93YWl0DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gX3QN
Cj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBpbWUNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ID4gPiBFeGFtcGxlOiBCYXNlIG9uIFRCZnJlcSBpcyA0MU1IWi4NCj4gPiA+ID4gPiA+ID4gPiA+
ID4gPiA+ID4gPiAxfjQ4KG5zKTogVEJbNjNdDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
NDl+OTcobnMpOiBUQls2Ml0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA5OH4xOTUobnMp
OiBUQls2MV0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiAxOTZ+MzkwKG5zKTogVEJbNjBd
DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gMzkxfjc4MChucyk6IFRCWzU5XQ0KPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+IDc4MX4xNTYwKG5zKTogVEJbNThdIC4uLg0KPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gU2lnbmVkLW9m
Zi1ieTogV2FuZyBEb25nc2hlbmcNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA8ZG9uZ3No
ZW5nLndhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiAtLS0N
Cj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiAqdjU6DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gQ2hhbmdlIGdldF9pZGxlX3RpY2tzX2JpdCBmdW5jdGlvbiBpbXBsZW1lbnRhdGlvbi4N
Cj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ICp2NDoNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBNb3ZlIGNvZGUgZnJvbSA4NXh4L2Nv
bW1vbi5jIHRvIGtlcm5lbC9zeXNmcy5jLg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+DQo+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gUmVtb3ZlIGhhc19wdzIwX2FsdGl2ZWNfaWRsZSBm
dW5jdGlvbi4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+IENoYW5nZSB3YWl0ICJlbnRyeV9iaXQiIHRvIHdhaXQgdGltZS4NCj4gPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IGRpZmYgLS1n
aXQgYS9hcmNoL3Bvd2VycGMva2VybmVsL3N5c2ZzLmMNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ID4gPiBiL2FyY2gvcG93ZXJwYy9rZXJuZWwvc3lzZnMuYw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ID4gPiBpbmRleA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IDI3YTkwYjkuLjEwZDExMjgg
MTAwNjQ0DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gLS0tIGEvYXJjaC9wb3dlcnBjL2tl
cm5lbC9zeXNmcy5jDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKysrIGIvYXJjaC9wb3dl
cnBjL2tlcm5lbC9zeXNmcy5jDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gQEAgLTg1LDYg
Kzg1LDI4NCBAQA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+IF9fc2V0dXAoInNtdC1zbm9v
emUtZGVsYXk9IiwNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gc2V0dXBfc210X3Nub296ZV9k
ZWxheSk7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiAgI2VuZGlmIC8qIENPTkZJR19QUEM2NCAqLw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKyNpZmRlZiBDT05GSUdfRlNMX1NP
Qw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsjZGVmaW5lIE1BWF9CSVQJCQkJNjMNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
K3N0YXRpYyB1NjQgcHcyMF93dDsgc3RhdGljIHU2NA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ICthbHRpdmVjX2lkbGVfd3Q7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICtzdGF0aWMgdW5zaWduZWQgaW50IGdldF9pZGxlX3Rp
Y2tzX2JpdCh1NjQgbnMpIHsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArCXU2NCBjeWNs
ZTsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gKwlpZiAobnMgPj0gMTAwMDApDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKwkJ
Y3ljbGUgPSBkaXZfdTY0KG5zICsgNTAwLCAxMDAwKSAqDQo+ID4gPiA+ID4gPiA+IHRiX3RpY2tz
X3Blcl91c2VjOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJZWxzZQ0KPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiA+ICsJCWN5Y2xlID0gZGl2X3U2NChucyAqDQo+ID4gdGJfdGlja3Nf
cGVyX3VzZWMsDQo+ID4gPiA+ID4gMTAwMCk7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
Kw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJaWYgKCFjeWNsZSkNCj4gPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiArCQlyZXR1cm4gMDsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
PiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKwlyZXR1cm4gaWxvZzIoY3ljbGUpOyB9
DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ICtzdGF0aWMgdm9pZCBkb19zaG93X3B3cm1ndGNyMCh2b2lkICp2YWwpIHsNCj4gPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gPiArCXUzMiAqdmFsdWUgPSB2YWw7DQo+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJKnZhbHVlID0gbWZz
cHIoU1BSTl9QV1JNR1RDUjApOyB9DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICtzdGF0aWMgc3NpemVfdCBzaG93X3B3MjBfc3RhdGUo
c3RydWN0IGRldmljZQ0KPiA+ICpkZXYsDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKwkJ
CQlzdHJ1Y3QgZGV2aWNlX2F0dHJpYnV0ZQ0KPiA+ICphdHRyLA0KPiA+ID4gPiA+IGNoYXINCj4g
PiA+ID4gPiA+ID4gKmJ1Zikgew0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdTMyIHZh
bHVlOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdW5zaWduZWQgaW50IGNwdSA9IGRl
di0+aWQ7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ICsJc21wX2NhbGxfZnVuY3Rpb25fc2luZ2xlKGNwdSwNCj4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gPiArZG9fc2hvd19wd3JtZ3RjcjAsICZ2YWx1ZSwgMSk7DQo+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdmFsdWUg
Jj0gUFdSTUdUQ1IwX1BXMjBfV0FJVDsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKwlyZXR1cm4gc3ByaW50ZihidWYsICIldVxuIiwg
dmFsdWUgPyAxIDoNCj4gPiAwKTsgfQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArc3RhdGljIHZvaWQgZG9fc3RvcmVfcHcyMF9zdGF0
ZSh2b2lkICp2YWwpIHsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArCXUzMiAqdmFsdWUg
PSB2YWw7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKwl1MzIgcHcyMF9zdGF0ZTsNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
KwlwdzIwX3N0YXRlID0gbWZzcHIoU1BSTl9QV1JNR1RDUjApOw0KPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ICsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArCWlmICgqdmFsdWUpDQo+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKwkJcHcyMF9zdGF0ZSB8PSBQV1JNR1RDUjBfUFcy
MF9XQUlUOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJZWxzZQ0KPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ICsJCXB3MjBfc3RhdGUgJj0gflBXUk1HVENSMF9QVzIwX1dBSVQ7DQo+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ICsJbXRzcHIoU1BSTl9QV1JNR1RDUjAsIHB3MjBfc3RhdGUpOyB9DQo+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICtzdGF0aWMgc3NpemVf
dCBzdG9yZV9wdzIwX3N0YXRlKHN0cnVjdCBkZXZpY2UNCj4gPiAqZGV2LA0KPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ICsJCQkJc3RydWN0IGRldmljZV9hdHRyaWJ1dGUNCj4gPiAqYXR0ciwN
Cj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArCQkJCWNvbnN0IGNoYXIgKmJ1Ziwgc2l6ZV90
DQo+ID4gY291bnQpDQo+ID4gPiA+ID4gew0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJ
dTMyIHZhbHVlOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdW5zaWduZWQgaW50IGNw
dSA9IGRldi0+aWQ7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ICsJaWYgKGtzdHJ0b3UzMihidWYsIDAsICZ2YWx1ZSkpDQo+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gKwkJcmV0dXJuIC1FSU5WQUw7DQo+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJaWYgKHZhbHVlID4g
MSkNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArCQlyZXR1cm4gLUVJTlZBTDsNCj4gPiA+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKwlz
bXBfY2FsbF9mdW5jdGlvbl9zaW5nbGUoY3B1LA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ICtkb19zdG9yZV9wdzIwX3N0YXRlLCAmdmFsdWUsIDEpOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ID4gPiA+ICsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArCXJldHVybiBjb3VudDsgfQ0K
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
PiArc3RhdGljIHNzaXplX3Qgc2hvd19wdzIwX3dhaXRfdGltZShzdHJ1Y3QNCj4gPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiArZGV2aWNlDQo+ID4gPiA+ICpkZXYsDQo+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gKwkJCQlzdHJ1Y3QgZGV2aWNlX2F0dHJpYnV0ZQ0KPiA+ICphdHRyLA0KPiA+
ID4gPiA+IGNoYXINCj4gPiA+ID4gPiA+ID4gKmJ1Zikgew0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+
ID4gPiA+ICsJdTMyIHZhbHVlOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdTY0IHRi
X2N5Y2xlOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJczY0IHRpbWU7DQo+ID4gPiA+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJdW5z
aWduZWQgaW50IGNwdSA9IGRldi0+aWQ7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0K
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICsJaWYgKCFwdzIwX3d0KSB7DQo+ID4gPiA+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gKwkJc21wX2NhbGxfZnVuY3Rpb25fc2luZ2xlKGNwdSwNCj4gPiA+
ID4gPiBkb19zaG93X3B3cm1ndGNyMCwNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArJnZh
bHVlLA0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+IDEpOw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ICsJCXZhbHVlID0gKHZhbHVlICYNCj4gPiBQV1JNR1RDUjBfUFcyMF9FTlQpID4+DQo+ID4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+IAlQV1JNR1RDUjBfUFcyMF9FTlRfU0hJRlQ7
DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ICsJCXRiX2N5Y2xlID0gKDEgPDwgKE1BWF9CSVQgLSB2YWx1ZSkpICoNCj4gPiAyOw0KPiA+
ID4gPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiBJcyB2YWx1
ZSA9IDAgYW5kIHZhbHVlID0gMSBsZWdhbD8gVGhlc2Ugd2lsbA0KPiA+ID4gPiA+ID4gPiA+ID4g
PiA+ID4gPiBtYWtlIHRiX2N5Y2xlID0gMCwNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gPiArCQl0aW1lID0gZGl2X3U2NCh0Yl9jeWNsZSAqIDEw
MDAsDQo+ID4gPiA+ID4gdGJfdGlja3NfcGVyX3VzZWMpDQo+ID4gPiA+ID4gPiA+IC0gMTsNCj4g
PiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4gQW5kIHRp
bWUgPSAtMTsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4g
PiA+IFBsZWFzZSBsb29rIGF0IHRoZSBlbmQgb2YgdGhlIGZ1bmN0aW9uLCA6KQ0KPiA+ID4gPiA+
ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiA+ICJyZXR1cm4gc3ByaW50Zihi
dWYsICIlbGx1XG4iLCB0aW1lID4gMCA/IHRpbWUgOiAwKTsiDQo+ID4gPiA+ID4gPiA+ID4gPiA+
ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiBJIGtub3cgeW91IHJldHVybiAwIGlmIHZhbHVlID0g
MC8xLCBteSBxdWVzdGlvbiB3YXMNCj4gPiA+ID4gPiA+ID4gPiA+ID4gPiB0aGF0LCBpcyB0aGlz
IGNvcnJlY3QgYXMgcGVyIHNwZWNpZmljYXRpb24/DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4g
PiA+ID4gPiA+ID4gPiA+ID4gPiBBaGgsIGFsc28gZm9yICJ2YWx1ZSIgdXB0byA3IHlvdSB3aWxs
IHJldHVybiAwLCBubz8NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4g
PiBJZiB2YWx1ZSA9IDAsIE1BWF9CSVQgLSB2YWx1ZSA9IDYzIHRiX2N5Y2xlID0NCj4gPiA+ID4g
PiA+ID4gPiA+ID4gMHhmZmZmZmZmZl9mZmZmZmZmZiwgdGJfY3ljbGUgKiAxMDAwIHdpbGwgb3Zl
cmZsb3csDQo+ID4gPiA+ID4gPiA+ID4gPiA+IGJ1dCB0aGlzDQo+ID4gPiA+ID4gc2l0dWF0aW9u
IGlzIG5vdCBwb3NzaWJsZS4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gQmVjYXVzZSBpZiB0aGUgInZh
bHVlID0gMCIgbWVhbnMgdGhpcyBmZWF0dXJlIHdpbGwgYmUNCj4gPiA+ID4gImRpc2FibGUiLg0K
PiA+ID4gPiA+ID4gPiA+ID4gPiBOb3cgVGhlIGRlZmF1bHQgd2FpdCBiaXQgaXMgNTAoTUFYX0JJ
VCAtIHZhbHVlLCB2YWx1ZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiA9IDEzKSwgdGhlIFBXMjAvQWx0
aXZlYyBJZGxlIHdhaXQgZW50cnkgdGltZSBpcyBhYm91dA0KPiA+ID4gPiA+ID4gPiA+ID4gPiAx
bXMsIHRoaXMgdGltZSBpcyB2ZXJ5IGxvbmcgZm9yIHdhaXQgaWRsZSB0aW1lLCBhbmQNCj4gPiA+
ID4gPiA+ID4gPiA+ID4gaXQncyBjYW5ub3QgYmUgaW5jcmVhc2VkKG1lYW5zIChNQVhfQklUDQo+
ID4gPiA+ID4gPiA+ID4gPiA+IC0gdmFsdWUpDQo+ID4gPiA+ID4gPiA+ID4gPiBjYW5ub3QgZ3Jl
YXRlciB0aGFuIDUwKS4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBXaGF0
IHlvdSBzYWlkIGlzIG5vdCBvYnZpb3VzIGZyb20gY29kZSBhbmQgc28gYXQgbGVhc3QNCj4gPiA+
ID4gPiA+ID4gPiA+IHdyaXRlIGEgY29tbWVudCB0aGF0IHZhbHVlIHdpbGwgYmUgYWx3YXlzID49
IDEzIG9yIHZhbHVlDQo+ID4gPiA+ID4gPiA+ID4gPiB3aWxsIG5ldmVyIGJlIGxlc3MgdGhhbiA8
IDggYW5kIGJlbG93IGNhbGN1bGF0aW9uIHdpbGwNCj4gPiA+ID4gPiA+ID4gPiA+IG5vdCBvdmVy
Zmxvdy4gbWF5IGJlIGVycm9yIG91dCBpZiB2YWx1ZSBpcyBsZXNzIHRoYW4gOC4NCj4gPiA+ID4g
PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gVGhlICJ2YWx1ZSIgbGVzcyB0aGFuIDEwLCB0aGlz
IHdpbGwgb3ZlcmZsb3cuDQo+ID4gPiA+ID4gPiA+ID4gVGhlcmUgaXMgbm90IGVycm9yLCBUaGUg
Y29kZSBJIGtuZXcgaXQgY291bGQgbm90IGJlIGxlc3MNCj4gPiA+ID4gPiA+ID4gPiB0aGFuIDEw
LCB0aGF0J3Mgd2h5IEkgdXNlIHRoZSBmb2xsb3dpbmcgY29kZS4gOikNCj4gPiA+ID4gPiA+ID4N
Cj4gPiA+ID4gPiA+ID4gSSBhbSBzb3JyeSB0byBwZXJzaXN0IGJ1dCB0aGlzIGlzIG5vdCBhYm91
dCB3aGF0IHlvdSBrbm93LA0KPiA+ID4gPiA+ID4gPiB0aGlzIGlzIGFib3V0IGhvdyBjb2RlIGlz
IHJlYWQgYW5kIGNvZGUgZG9lcyBub3Qgc2F5IHdoYXQNCj4gPiA+ID4gPiA+ID4geW91IGtub3cs
IHNvIGFkZCBhIGNvbW1lbnQgYXQgbGVhc3QgYW5kIGVycm9yIG91dC93YXJuIHdoZW4NCj4gPiA+
ID4gPiA+ID4gInZhbHVlIiBpcyBsZXNzIHRoYW4gYQ0KPiA+ID4gPiA+IGNlcnRhaW4gbnVtYmVy
Lg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gU29ycnkgZm9yIHRoZSBsYXRlIHRvIHJlc3Bv
bnNlIHRoZSBtYWlsLiBJZiBpdCBjYXVzZWQNCj4gPiA+ID4gPiA+IGNvbmZ1c2lvbiwgd2UgY2Fu
DQo+ID4gPiA+ID4gYWRkIGEgY29tbWVudC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBIb3cg
YWJvdXQgdGhlIGZvbGxvd2luZyBjb21tZW50Pw0KPiA+ID4gPiA+ID4gLyoNCj4gPiA+ID4gPiA+
ICAqIElmIHRoZSAidmFsdWUiIGxlc3MgdGhhbiAxMCwgdGhpcyB3aWxsIG92ZXJmbG93Lg0KPiA+
ID4gPiA+ID4gICogRnJvbSBiZW5jaG1hcmsgdGVzdCwgdGhlIGRlZmF1bHQgd2FpdCBiaXQgd2ls
bCBub3QgYmUgc2V0DQo+ID4gPiA+ID4gPiBsZXNzIHRoYW4NCj4gPiA+ID4gPiAxMGJpdC4NCj4g
PiA+ID4gPiA+ICAqIEJlY2F1c2UgMTAgYml0IGNvcnJlc3BvbmRzIHRvIHRoZSB3YWl0IGVudHJ5
IHRpbWUgaXMNCj4gPiA+ID4gPiA+IDQzOTM3NTU3MzQwMTk5OTYwOShucyksDQo+ID4gPiA+ID4g
PiAgKiBmb3Igd2FpdC1lbnRyeS1pZGxlIHRpbWUgdGhpcyB2YWx1ZSBsb29rcyB0b28gbG9uZywg
YW5kIHdlDQo+ID4gPiA+ID4gPiBjYW5ub3QgdXNlIHRob3NlDQo+ID4gPiA+ID4gPiAgKiAibG9u
ZyIgdGltZSBhcyBhIGRlZmF1bHQgd2FpdC1lbnRyeSB0aW1lLiBTbyBvdmVyZmxvdyBjb3VsZA0K
PiA+ID4gPiA+ID4gbm90IGhhdmUgaGFwcGVuZWQNCj4gPiA+ID4gPiA+ICAqIGFuZCB3ZSB1c2Ug
dGhpcyBjYWxjdWxhdGlvbiBtZXRob2QgdG8gZ2V0IHdhaXQtZW50cnktaWRsZSB0aW1lLg0KPiA+
ID4gPiA+ID4gICovDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJZiB0aGVyZSdzIHRvIGJlIGEgbGlt
aXQgb24gdGhlIHRpbWVzIHdlIGFjY2VwdCwgbWFrZSBpdCBleHBsaWNpdC4NCj4gPiA+ID4gPiBD
aGVjayBmb3IgaXQgYmVmb3JlIGRvaW5nIGFueSBjb252ZXJzaW9ucywgYW5kIHJldHVybiBhbiBl
cnJvcg0KPiA+ID4gPiA+IGlmIHVzZXJzcGFjZSB0cmllcyB0byBzZXQgaXQuDQo+ID4gPiA+ID4N
Cj4gPiA+ID4gVGhlIGJyYW5jaCBvbmx5IHVzZSB0byByZWFkIGRlZmF1bHQgd2FpdC1lbnRyeS10
aW1lLg0KPiA+ID4gPiBXZSBoYXZlIG5vIGxpbWl0IHRoZSB1c2VyJ3MgaW5wdXQsIGFuZCB3ZSBj
YW4ndCByZXN0cmljdC4gT25jZSB0aGUNCj4gPiA+ID4gdXNlciBzZXQgdGhlIHdhaXQtZW50cnkt
dGltZSwgdGhlIGNvZGUgd2lsbCBkbyBhbm90aGVyIGJyYW5jaC4NCj4gPiA+ID4NCj4gPiA+DQo+
ID4gPiBIaSBzY290dCwNCj4gPiA+IERvIHlvdSBoYXZlIGFueSBjb21tZW50cyBhYm91dCB0aGlz
IHBhdGNoPw0KPiA+ID4gSSB3aWxsIGFkZCB0aGUgY29tbWVudCBhbmQgc2VuZCB0aGlzIHBhdGNo
IGFnYWluLg0KPiA+DQo+ID4gV2hhdCBkbyB5b3UgbWVhbiBieSAiYW5kIHdlIGNhbid0IHJlc3Ry
aWN0Ij8gIFdoeSBub3Q/DQo+ID4NCj4gPiBXaHkgaXMgaXQgb25seSB1c2VkIHRvIHJlYWQgdGhl
IGRlZmF1bHQsIGFuZCBub3QgdGhlIGN1cnJlbnQgdmFsdWU/DQo+ID4NCj4gV2UgYWxyZWFkeSBo
YXZlIGEgdmFyaWFibGUgd2hpY2ggdmFsdWUgaXMgc2V0IGJ5IHRoZSB1c2VyLCBhcyB3ZSBoYXZl
IGRpc2N1c3NlZA0KPiBiZWZvcmUuDQo+IA0KPiBXaGVuIHRoZSBzeXN0ZW0gYm9vdC11cC4gQmVm
b3JlIHVzZXIgc2V0IHRoZSB3YWl0LWVudHJ5LXRpbWUsIHdlIG5lZWQgdG8gcmV0dXJuDQo+IGEg
ZGVmYXVsdCB3YWl0LWVudHJ5LXRpbWUsIGlmIHRoZSB1c2VyIHJlYWQgdGhpcyBzeXMtaW50ZXJm
YWNlLiBUaGUgZGVmYXVsdA0KPiB3YWl0LWVudHJ5LXRpbWUgaXMgY29udmVydGVkIGJ5IHdhaXQt
Yml0Lg0KPiANCj4gT25jZSB0aGUgdXNlciBzZXQgdGhlIHN5cy1pbnRlcmZhY2UsIGEgdmFyaWFi
bGUgd2lsbCBiZSB1c2VkIHRvIHNhdmUgaXQuIEFuZA0KPiB3aGVuIHRoZSB1c2VyIHJlYWQgc3lz
LWludGVyZmFjZSB3ZSB3aWxsIHJldHVybiBiYWNrIHRoZSB2YXJpYWJsZS4NCg0KV2hpbGUgd2Ug
YXJlIG5vdCAicmVzdHJpY3RpbmcgdXNlciBkZWZpbmVkIHZhbHVlIiBvciAiZGVmaW5lIHNhbWUg
cmVzdHJpY3Rpb24gZm9yIHVzZXIgZGVmaW5lZCBhbmQgZGVmYXVsdCIsIGNhbiB3ZSBoYXZlIG9u
bHkgb25lIGZsb3cgb2YgY2FsY3VsYXRpb24gYW5kIHNldHRpbmcgcmF0aGVyIHRoYW4gY29uZGl0
aW9uYWwgYmFzZWQgb24gdXNlciBoYXZlIHNldCBvciBub3Qgc2V0PyANCg0KLUJoYXJhdA0KDQo+
IA0KPiAtZG9uZ3NoZW5nDQoNCg==
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/kvm: remove redundant assignment
From: Paul Mackerras @ 2013-11-06 5:04 UTC (permalink / raw)
To: Liu Ping Fan; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <1383637364-14691-3-git-send-email-pingfank@linux.vnet.ibm.com>
On Tue, Nov 05, 2013 at 03:42:44PM +0800, Liu Ping Fan wrote:
> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> ---
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 28160ac..7682837 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -731,7 +731,6 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct kvm_vcpu *vcpu,
> lock_rmap(rmap);
>
> /* Check if we might have been invalidated; let the guest retry if so */
> - ret = RESUME_GUEST;
> if (mmu_notifier_retry(vcpu->kvm, mmu_seq)) {
> unlock_rmap(rmap);
> goto out_unlock;
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/kvm: fix rare but potential deadlock scene
From: Paul Mackerras @ 2013-11-06 5:04 UTC (permalink / raw)
To: Liu Ping Fan; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <1383637364-14691-2-git-send-email-pingfank@linux.vnet.ibm.com>
On Tue, Nov 05, 2013 at 03:42:43PM +0800, Liu Ping Fan wrote:
> Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
> realmode, so it can trigger the deadlock.
Good catch, we should have preemption disabled while ever we have a
HPTE locked.
> @@ -474,8 +474,10 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu *vcpu, gva_t eaddr,
> }
>
> /* Find the HPTE in the hash table */
> + preempt_disable();
> index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v,
> HPTE_V_VALID | HPTE_V_ABSENT);
> + preempt_enable();
Which means we need to add the preempt_enable after unlocking the
HPTE, not here.
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/kvm: simplify the entering logic for secondary thread
From: Paul Mackerras @ 2013-11-06 5:01 UTC (permalink / raw)
To: Liu Ping Fan; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc
In-Reply-To: <1383637364-14691-1-git-send-email-pingfank@linux.vnet.ibm.com>
On Tue, Nov 05, 2013 at 03:42:42PM +0800, Liu Ping Fan wrote:
> After the primary vcpu changes vcore_state to VCORE_RUNNING, there is
> very little chance to schedule to secondary vcpu. So if we change the
Why do you say there is very little chance to run the secondary vcpu?
> code sequence around set vcore_state to VCORE_RUNNING and disable
> preemption, we lost little. But we simplify the entering logi, based on
> the fact that if primary vcpu runs, the secondary vcpu can not be scheduled.
If a vcpu does a hypercall or something else that requires the host
(kernel or userspace) to do something, that can happen in the context
of the vcpu task for that vcpu. That vcpu task can run on another
core (unless it has been pinned). When it is finished we would like
the vcpu to continue executing in the guest as soon as possible. The
code that you remove in this patch enables that to happen without
having to wait until the other threads exit the guest. So I don't
think it is a good idea to remove this code.
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
From: Benjamin Herrenschmidt @ 2013-11-06 3:58 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev, linux-usb, Alan Stern
In-Reply-To: <2440701.siW6M1PPWz@mexican>
On Wed, 2013-11-06 at 14:50 +1100, Alistair Popple wrote:
> Actually a grep of "usb-ehci" turns up the ehci-ppc-of driver which I somehow
> missed. This driver works and uses .compatible = "usb-ehci" so I can use that
> instead if that is preferable?
>
> However it is basically the same as the ehci-platform driver so I guess at
> some point the two should be merged...
I think the split predates the grand unification of "of" driver and platform,
so yes they should.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-06 3:53 UTC (permalink / raw)
To: Timur Tabi, Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Huan Wang,
perex@perex.cz, Shawn Guo, LW@KARO-electronics.de,
linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org,
grant.likely@linaro.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, oskar@scara.com, Fabio Estevam,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, Zhengxiong Jin, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5279B822.9010401@tabi.org>
> >> If there are any comments that say PPC but are not PPC-specific, that
> >> >should be fixed.
> > Yes, find it.
> >
> > The comments is in "sound/soc/fsl/Makefile" :
> > +++++++++++
> > "# Freescale PowerPC SSI/DMA Platform Support"
> > -----------
> >
> > But fsl-spdif.o is also under it.
> > And this is also support ARM and PowerPC platforms at the same time ?
> > If so, the comments should be modified to :
> > +++++++++++
> > "# Freescale PowerPC and ARM SSI/DMA Platform Support"
> > -----------
>=20
> Yes, this should be changed.
>=20
How about :
+++++++++
"# Freescale PowerPC and ARM SSI/DMA/SAI/SPDIF Platform Support"=09
---------
?
^ permalink raw reply
* Re: [PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
From: Alistair Popple @ 2013-11-06 3:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-usb, Alan Stern
In-Reply-To: <1383681133.4776.95.camel@pasglop>
On Wed, 6 Nov 2013 06:52:13 Benjamin Herrenschmidt wrote:
[snip]
>
> Why ? Do we need to add an entry for every platform in there ? Besides,
> it probably should be the SoC name not the platform here....
>
> Why not simply a generic compatible "usb-ehci" ? It's a standard
> programming interface, there are no specific quirks, we shouldn't
> need to have to add new entries to the driver like that for every
> new SoC/platform.
>
Actually a grep of "usb-ehci" turns up the ehci-ppc-of driver which I somehow
missed. This driver works and uses .compatible = "usb-ehci" so I can use that
instead if that is preferable?
However it is basically the same as the ehci-platform driver so I guess at
some point the two should be merged...
> > > @@ -229,7 +230,7 @@ static struct platform_driver ehci_platform_driver =
> > > {
> > >
> > > .owner = THIS_MODULE,
> > > .name = "ehci-platform",
> > > .pm = &ehci_platform_pm_ops,
> > >
> > > - .of_match_table = vt8500_ehci_ids,
> > > + .of_match_table = ehci_platform_ids,
> > >
> > > }
> > >
> > > };
> >
> > Acked-by: Alan Stern <stern@rowland.harvard.edu>
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Timur Tabi @ 2013-11-06 3:31 UTC (permalink / raw)
To: Li Xiubo, Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Huan Wang,
perex@perex.cz, Shawn Guo, LW@KARO-electronics.de,
linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org,
grant.likely@linaro.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, oskar@scara.com, Fabio Estevam,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, Zhengxiong Jin, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F82876A53@039-SN2MPN1-013.039d.mgd.msft.net>
Li Xiubo wrote:
>> If there are any comments that say PPC but are not PPC-specific, that
>> >should be fixed.
> Yes, find it.
>
> The comments is in "sound/soc/fsl/Makefile" :
> +++++++++++
> "# Freescale PowerPC SSI/DMA Platform Support"
> -----------
>
> But fsl-spdif.o is also under it.
> And this is also support ARM and PowerPC platforms at the same time ?
> If so, the comments should be modified to :
> +++++++++++
> "# Freescale PowerPC and ARM SSI/DMA Platform Support"
> -----------
Yes, this should be changed.
^ permalink raw reply
* RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-06 3:27 UTC (permalink / raw)
To: Timur Tabi, Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Huan Wang,
perex@perex.cz, Shawn Guo, LW@KARO-electronics.de,
linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org,
grant.likely@linaro.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, oskar@scara.com, Fabio Estevam,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, Zhengxiong Jin, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5278F1FA.1060706@tabi.org>
> > But fsl-ssi.o and fsl-spdif.o is based PowrePC platform? Which we can
> see from the comments.
>=20
> fsl_ssi was originally PPC-only, but it now supports PPC and ARM. You
> can see that from the git history.
>=20
> If there are any comments that say PPC but are not PPC-specific, that
> should be fixed.
Yes, find it.
The comments is in "sound/soc/fsl/Makefile" :
+++++++++++
"# Freescale PowerPC SSI/DMA Platform Support"
-----------
But fsl-spdif.o is also under it.
And this is also support ARM and PowerPC platforms at the same time ?
If so, the comments should be modified to :
+++++++++++
"# Freescale PowerPC and ARM SSI/DMA Platform Support"
-----------
Best Regards,
Xiubo
^ permalink raw reply
* [PATCH] powerpc/boot: Properly handle the base "of" boot wrapper
From: Benjamin Herrenschmidt @ 2013-11-06 3:09 UTC (permalink / raw)
To: linuxppc-dev
The wrapper script needs an explicit rule for the "of" boot
wrapper (generic wrapper, similar to pseries). Before
0c9fa29149d3726e14262aeb0c8461a948cc9d56 it was hanlded
implicitly by the statement:
platformo=$object/"$platform".o
But now that epapr.o needs to be added, that doesn't work
and an explicit rule must be added.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/boot/wrapper | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index ac16e99..2e1af74 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -147,6 +147,10 @@ link_address='0x400000'
make_space=y
case "$platform" in
+of)
+ platformo="$object/of.o $object/epapr.o"
+ make_space=n
+ ;;
pseries)
platformo="$object/of.o $object/epapr.o"
link_address='0x4000000'
^ permalink raw reply related
* RE: [PATCH V4 3/3] powerpc/85xx: Add TWR-P1025 board support
From: Xiaobo Xie @ 2013-11-06 2:31 UTC (permalink / raw)
To: Scott Wood; +Cc: Michael Johnston, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1380230838.24959.322.camel@snotra.buserror.net>
SGkgU2NvdHQsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBT
Y290dC1CMDc0MjENCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTMgNToyNyBBTQ0K
PiBUbzogWGllIFhpYW9iby1SNjMwNjENCj4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBsaW51eHBw
Yy1kZXZAbGlzdHMub3psYWJzLm9yZzsgSm9obnN0b24gTWljaGFlbC0NCj4gUjQ5NjEwDQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggVjQgMy8zXSBwb3dlcnBjLzg1eHg6IEFkZCBUV1ItUDEwMjUgYm9h
cmQgc3VwcG9ydA0KPiANCj4gPiA+ID4gPiA+ICsJLyogQ1MyIGZvciBEaXNwbGF5ICovDQo+ID4g
PiA+ID4gPiArCXNzZDEyODlAMiwwIHsNCj4gPiA+ID4gPiA+ICsJCSNhZGRyZXNzLWNlbGxzID0g
PDE+Ow0KPiA+ID4gPiA+ID4gKwkJI3NpemUtY2VsbHMgPSA8MT47DQo+ID4gPiA+ID4gPiArCQlj
b21wYXRpYmxlID0gInNzZDEyODkiOw0KPiA+ID4gPiA+ID4gKwkJcmVnID0gPDB4MiAweDAwMDAg
MHgwMDAyDQo+ID4gPiA+ID4gPiArCQkgICAgICAgMHgyIDB4MDAwMiAweDAwMDI+Ow0KPiA+ID4g
PiA+ID4gKwl9Ow0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gTm9kZSBuYW1lcyBzaG91bGQgYmUgZ2Vu
ZXJpYy4gIFdoYXQgZG9lcyBzc2QxMjg5IGRvPyAgSWYgdGhpcyBpcw0KPiA+ID4gPiA+IGFjdHVh
bGx5IHRoZSBkaXNwbGF5IGRldmljZSwgdGhlbiBpdCBzaG91bGQgYmUgY2FsbGVkDQo+ICJkaXNw
bGF5QDIsMCIuDQo+ID4gPiA+DQo+ID4gPiA+IE9LLiBUaGUgc3NkMTI4OSBpcyBhIExDRCBjb250
cm9sbGVyLg0KPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSG93IGFib3V0IGEgdmVuZG9y
IHByZWZpeCBvbiB0aGF0IGNvbXBhdGlibGU/ICBXaHkNCj4gPiA+ID4gPiAjYWRkcmVzcy1jZWxs
cy8jc2l6ZS0gY2VsbHMgZGVzcGl0ZSBubyBjaGlsZCBub2Rlcz8gIFdoZXJlIGlzIGENCj4gPiA+
ID4gPiBiaW5kaW5nIHRoYXQgc2F5cyB3aGF0IGVhY2ggb2YgdGhvc2UgdHdvIHJlZyByZXNvdXJj
ZXMgbWVhbj8NCj4gPiA+ID4NCj4gPiA+ID4gSSB3aWxsIGFkZCB0aGUgdmVuZG9yIHByZWZpeC4g
SSByZXZpZXcgdGhlIHNzZDEyODkgZHJpdmVyLCBhbmQgdGhlDQo+ID4gPiAjYWRkcmVzcy1jZWxs
cy8jc2l6ZS1jZWxscyB3ZXJlIHVuLXVzZWQuIEkgd2lsbCByZW1vdmUgdGhlbS4NCj4gPiA+DQo+
ID4gPiBBbmQgYSBiaW5kaW5nPw0KPiA+ID4NCj4gPiA+IFdoeSBkbyB5b3UgbmVlZCB0d28gc2Vw
YXJhdGUgcmVnIHJlc291cmNlcyByYXRoZXIgdGhhbiBqdXN0IDwyIDAgND4/DQo+ID4gPiBXaWxs
IHRoZXkgZXZlciBiZSBkaXNjb250aWd1b3VzPw0KPiA+DQo+ID4gW1hpZV0gSSByZXZpZXcgdGhl
IHNzZDEyODkgZHJpdmVyIGNvZGUsIGFuZCBmb3VuZCB0aGUgZHJpdmVyIG5lZWQgdHdvDQo+ID4g
cmVnIHJlc291cmNlcywNCj4gDQo+IFRoZSBkZXZpY2UgdHJlZSBkZXNjcmliZXMgdGhlIGhhcmR3
YXJlLCBub3QgdGhlIGN1cnJlbnQgc3RhdGUgb2YgTGludXgNCj4gZHJpdmVycy4gIEVzcGVjaWFs
bHkgZHJpdmVycyB0aGF0IGFyZW4ndCB5ZXQgaW4gTGludXguIDotKQ0KPiANCg0KT0ssIEkgd2ls
bCByZW1haW4gdGhlIGRpc3BsYXkgbm9kZS4NCg0KPiA+IGlmIGNoYW5nZSB0aGUgZHRzLCB0aGUg
ZHJpdmVyIGFsc28gc2hvdWxkIGJlIG1vZGlmaWVkIGFjY29yZGluZ2x5LiBTbw0KPiA+IEkgcmVt
b3ZlIHRoZSBzc2QxMjg5IG5vZGUgZnJvbSB0aGlzIHBhdGNoLiBJIHdpbGwgc3VibWl0IG5ldyBw
YXRjaA0KPiA+IGluY2x1ZGUgdGhlIGR0cyBtb2RpZmljYXRpb24sIHNzZDEyODkgZHJpdmVyIGFu
ZCB0aGUgYmluZGluZy4NCj4gDQo+IElkZWFsbHkgYWxsIGRldmljZXMgKGFuZCBiaW5kaW5ncykg
c2hvdWxkIGJlIGRlc2NyaWJlZCB3aGVuIHRoZSBkZXZpY2UNCj4gdHJlZSBpcyBpbml0YWxseSBh
ZGRlZCwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHlvdSBoYXZlIGEgZHJpdmVyIHlldC4NCj4gDQog
DQpJIHdpbGwgYWRkIGEgYmluZGluZyBkb2N1bWVudCBmb3IgdGhlIHNzZDEyODkgZGV2aWNlLg0K
DQo+IC1TY290dA0KPiANCi0gWGlhb2JvDQo=
^ permalink raw reply
* RE: [PATCH V5 1/2] powerpc/85xx: Add QE common init function
From: Xiaobo Xie @ 2013-11-06 2:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1380301237.24959.397.camel@snotra.buserror.net>
SGkgU2NvdHQsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBT
Y290dC1CMDc0MjENCj4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAyOCwgMjAxMyAxOjAxIEFN
DQo+IFRvOiBYaWUgWGlhb2JvLVI2MzA2MQ0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFi
cy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCBWNSAxLzJdIHBvd2VycGMvODV4eDogQWRkIFFF
IGNvbW1vbiBpbml0IGZ1bmN0aW9uDQo+IA0KPiBPbiBUaHUsIDIwMTMtMDktMjYgYXQgMTc6Mzcg
KzA4MDAsIFhpZSBYaWFvYm8gd3JvdGU6DQo+ID4gKyNpZmRlZiBDT05GSUdfUVVJQ0NfRU5HSU5F
DQo+ID4gK3ZvaWQgX19pbml0IG1wYzg1eHhfcWVfaW5pdCh2b2lkKQ0KPiA+ICt7DQo+ID4gKwlz
dHJ1Y3QgZGV2aWNlX25vZGUgKm5wOw0KPiA+ICsNCj4gPiArCW5wID0gb2ZfZmluZF9jb21wYXRp
YmxlX25vZGUoTlVMTCwgTlVMTCwgImZzbCxxZSIpOw0KPiA+ICsJaWYgKCFucCkgew0KPiA+ICsJ
CW5wID0gb2ZfZmluZF9ub2RlX2J5X25hbWUoTlVMTCwgInFlIik7DQo+ID4gKwkJaWYgKCFucCkg
ew0KPiA+ICsJCQlwcl9lcnIoIiVzOiBDb3VsZCBub3QgZmluZCBRdWljYyBFbmdpbmUgbm9kZVxu
IiwNCj4gPiArCQkJCQlfX2Z1bmNfXyk7DQo+ID4gKwkJCXJldHVybjsNCj4gPiArCQl9DQo+ID4g
Kwl9DQo+ID4gKw0KPiA+ICsJcWVfcmVzZXQoKTsNCj4gPiArCW9mX25vZGVfcHV0KG5wKTsNCj4g
DQo+IFlvdSdyZSBtaXNzaW5nIHRoZSBvZl9kZXZpY2VfaXNfYXZhaWxhYmxlKCkgY2hlY2s6DQoN
Ckkgd2lsbCBhZGQgdGhpcyBjaGVjaywgdGhhbmtzLg0KDQo+IA0KPiA+IC0JbnAgPSBvZl9maW5k
X2NvbXBhdGlibGVfbm9kZShOVUxMLCBOVUxMLCAiZnNsLHFlIik7DQo+ID4gLQlpZiAoIW5wKSB7
DQo+ID4gLQkJbnAgPSBvZl9maW5kX25vZGVfYnlfbmFtZShOVUxMLCAicWUiKTsNCj4gDQo+IC1T
Y290dA0KPiANCg0K
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Florian Fainelli @ 2013-11-06 2:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alistair Popple, linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383704240.4776.115.camel@pasglop>
2013/11/5 Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> On Wed, 2013-11-06 at 12:38 +1100, Alistair Popple wrote:
>> > Right, rgmii_mode_name() just has informative purposes and should be
>> > removed, I would suggest using standard device tree bindings
>> property
>> > (phy-mode) anyway such that you could use of_get_phy_mode() and use
>> > phy_interface_t types.
>>
>> Ok, that's what is currently done in the core IBM EMAC driver. As this
>> is used
>> just for informative purposes I will remove it. Thanks.
>
> Why ? Information is useful...
Not the way they are currently handled:
+ /* Check if we need to attach to a RGMII */
+ if (!rgmii_valid_mode(mode)) {
+ dev_err(&ofdev->dev, "unsupported settings !\n");
Considering that nothing useful is being printed, that or nothing at
all really looks identical to me.
--
Florian
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Benjamin Herrenschmidt @ 2013-11-06 2:17 UTC (permalink / raw)
To: Alistair Popple; +Cc: netdev, Florian Fainelli, linuxppc-dev, David S. Miller
In-Reply-To: <9250529.5UedqhaNce@mexican>
On Wed, 2013-11-06 at 12:38 +1100, Alistair Popple wrote:
> > Right, rgmii_mode_name() just has informative purposes and should be
> > removed, I would suggest using standard device tree bindings
> property
> > (phy-mode) anyway such that you could use of_get_phy_mode() and use
> > phy_interface_t types.
>
> Ok, that's what is currently done in the core IBM EMAC driver. As this
> is used
> just for informative purposes I will remove it. Thanks.
Why ? Information is useful...
Ben.
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Alistair Popple @ 2013-11-06 1:38 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, linuxppc-dev, David S. Miller
In-Reply-To: <CAGVrzcYzBtDcxYXDopOJn_=vW_58SFs9y0uKeGNB9TDPh6J4wg@mail.gmail.com>
On Tue, 5 Nov 2013 16:16:08 Florian Fainelli wrote:
[snip]
> 2013/11/5 Alistair Popple <alistair@popple.id.au>:
> >> Any reasons why you are duplicating what is available in
> >> drivers/of/of_net.c ::of_get_phy_mode()?
> >
> > Unless I'm missing something of_get_phy_mode() is going the other way.
> > rgmii_mode_name() is converting PHY_MODE_* into a human-readable string. I
> > couldn't find any obvious kernel method to do this but maybe I missed it?
>
> Right, rgmii_mode_name() just has informative purposes and should be
> removed, I would suggest using standard device tree bindings property
> (phy-mode) anyway such that you could use of_get_phy_mode() and use
> phy_interface_t types.
Ok, that's what is currently done in the core IBM EMAC driver. As this is used
just for informative purposes I will remove it. Thanks.
Regards,
Alistair
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Alistair Popple @ 2013-11-06 1:34 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383693110.2868.17.camel@bwh-desktop.uk.level5networks.com>
On Tue, 5 Nov 2013 23:11:50 Ben Hutchings wrote:
> On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote:
[snip]
> > It's an SoC bit so there's little point making it generally
> > selectable by the user.
>
> I think a better way to do this is:
>
> config IBM_EMAC_RGMII_WOL
> bool "IBM EMAC RGMII wake-on-LAN support"
> depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST
> default y if MY_WONDERFUL_NEW_SOC
>
> Then anyone making an API change that affects this driver can check that
> it still complies.
The method used in this patch is the same as what is currently used by the
other IBM EMAC PHY interfaces (eg. config IBM_EMAC_ZMII etc). I'm happy to
send a patch to update all of those as well for consistency but that would
mean adding what each platform requires into EMACS Kconfig as well.
Personally I think it is nicer to keep the definitions of what each platform
requires in one place (ie. arch/powerpc/platforms/44x/Kconfig) as it is
consistent with what we do for other 44x drivers, however I am happy to use
the above method if people think it's better.
Alternatively we could do something like this:
config IBM_EMAC_RGMII_WOL
bool
default y if COMPILE_TEST
default n
This would leave the platform dependencies as they are currently but still
allow compile testing.
Regards,
Alistair
> Ben.
>
> > Alistair: The commit name should be different, it's not a PHY you are
> > adding, it's a PHY interface (the PHY itself is off chip).
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Florian Fainelli @ 2013-11-06 0:16 UTC (permalink / raw)
To: Alistair Popple; +Cc: netdev, linuxppc-dev, David S. Miller
In-Reply-To: <81419762.0SyAdYsUqu@mexican>
2013/11/5 Alistair Popple <alistair@popple.id.au>:
> On Tue, 5 Nov 2013 10:47:22 Florian Fainelli wrote:
>> [snip]
>>
>> > +/* RGMII bridge supports only GMII/TBI and RGMII/RTBI PHYs */
>> > +static inline int rgmii_valid_mode(int phy_mode)
>> > +{
>> > + return phy_mode == PHY_MODE_GMII ||
>> > + phy_mode == PHY_MODE_MII ||
>> > + phy_mode == PHY_MODE_RGMII ||
>> > + phy_mode == PHY_MODE_TBI ||
>> > + phy_mode == PHY_MODE_RTBI;
>> > +}
>> > +
>> > +static inline const char *rgmii_mode_name(int mode)
>> > +{
>> > + switch (mode) {
>> > + case PHY_MODE_RGMII:
>> > + return "RGMII";
>> > + case PHY_MODE_TBI:
>> > + return "TBI";
>> > + case PHY_MODE_GMII:
>> > + return "GMII";
>> > + case PHY_MODE_MII:
>> > + return "MII";
>> > + case PHY_MODE_RTBI:
>> > + return "RTBI";
>> > + default:
>> > + BUG();
>> > + }
>>
>> Any reasons why you are duplicating what is available in
>> drivers/of/of_net.c ::of_get_phy_mode()?
>
> Unless I'm missing something of_get_phy_mode() is going the other way.
> rgmii_mode_name() is converting PHY_MODE_* into a human-readable string. I
> couldn't find any obvious kernel method to do this but maybe I missed it?
Right, rgmii_mode_name() just has informative purposes and should be
removed, I would suggest using standard device tree bindings property
(phy-mode) anyway such that you could use of_get_phy_mode() and use
phy_interface_t types.
--
Florian
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Alistair Popple @ 2013-11-06 0:08 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, linuxppc-dev, David S. Miller
In-Reply-To: <CAGVrzcZQ26kbim2piOwrvpyOcSaTET5da7Yh4GWv+erfuOBDhQ@mail.gmail.com>
On Tue, 5 Nov 2013 10:47:22 Florian Fainelli wrote:
> [snip]
>
> > +/* RGMII bridge supports only GMII/TBI and RGMII/RTBI PHYs */
> > +static inline int rgmii_valid_mode(int phy_mode)
> > +{
> > + return phy_mode == PHY_MODE_GMII ||
> > + phy_mode == PHY_MODE_MII ||
> > + phy_mode == PHY_MODE_RGMII ||
> > + phy_mode == PHY_MODE_TBI ||
> > + phy_mode == PHY_MODE_RTBI;
> > +}
> > +
> > +static inline const char *rgmii_mode_name(int mode)
> > +{
> > + switch (mode) {
> > + case PHY_MODE_RGMII:
> > + return "RGMII";
> > + case PHY_MODE_TBI:
> > + return "TBI";
> > + case PHY_MODE_GMII:
> > + return "GMII";
> > + case PHY_MODE_MII:
> > + return "MII";
> > + case PHY_MODE_RTBI:
> > + return "RTBI";
> > + default:
> > + BUG();
> > + }
>
> Any reasons why you are duplicating what is available in
> drivers/of/of_net.c ::of_get_phy_mode()?
Unless I'm missing something of_get_phy_mode() is going the other way.
rgmii_mode_name() is converting PHY_MODE_* into a human-readable string. I
couldn't find any obvious kernel method to do this but maybe I missed it?
Regards,
Alistair
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Arnaud Ebalard @ 2013-11-05 23:14 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, netdev, linux-kernel,
Jason Gunthorpe, Lennert Buytenhek, linuxppc-dev, David Miller,
linux-arm-kernel
In-Reply-To: <52796E82.5010800@gmail.com>
Hi,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> writes:
> On 11/05/2013 11:12 PM, Arnaud Ebalard wrote:
>> Hi Jason,
>>
>> Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
>>
>>> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
>>> present' made the call to phy_scan optional, if the DT has a link to
>>> the phy node.
>>>
>>> However phy_scan has the side effect of calling phy_addr_set, which
>>> writes the phy MDIO address to the ethernet controller. If phy_addr_set
>>> is not called, and the bootloader has not set the correct address then
>>> the driver will fail to function.
>>
>> Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
>> (Armada 370 based) which I had put on a todo list and temporarily
>
> Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta,
> are you sure it is (was) related to Jason's fix?
Thanks for pointing this, Sebastian and my apologies for the noise.
Jason's fix is indeed for a file which is not compiled for my RN102.
As the problem perfectly matched the issue I had and current kernel w/
the patch applied does indeed fix it, I did not try and do the test w/o
the patch applied. It would have showed the problem was fixed by
something else in 3.12. Well, I spent some time digging the changes on
mvneta.c and:
commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c
Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Wed Sep 4 16:21:18 2013 +0200
net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
This commit fixes a long-standing bug that has been reported by many
users: on some Armada 370 platforms, only the network interface that
has been used in U-Boot to tftp the kernel works properly in
Linux. The other network interfaces can see a 'link up', but are
unable to transmit data. The reports were generally made on the Armada
370-based Mirabox, but have also been given on the Armada 370-RD
board.
[SNIP]
$ git tag --contains 714086029116
v3.12
v3.12-rc1
v3.12-rc2
v3.12-rc3
v3.12-rc4
v3.12-rc5
v3.12-rc6
v3.12-rc7
So the problem was indeed fixed at the beginning of 3.12 series by Thomas.
Anyway, my bad and thanks again for pointing it out.
Cheers,
a+
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Ben Hutchings @ 2013-11-05 23:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alistair Popple, linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383681240.4776.97.camel@pasglop>
On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2013-11-05 at 18:16 +0000, Ben Hutchings wrote:
> > On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
> > [...]
> > > --- a/drivers/net/ethernet/ibm/emac/Kconfig
> > > +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> > > @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> > > bool
> > > default n
> > >
> > > +config IBM_EMAC_RGMII_WOL
> > > + bool
> > > + default n
> > > +
> > [...]
> >
> > So no-one can even build-test this at present!
>
> Patch 7/7 adds the select to the platform, isn't that sufficient ?
I suppose so, but I don't think that went to netdev.
> It's an SoC bit so there's little point making it generally
> selectable by the user.
I think a better way to do this is:
config IBM_EMAC_RGMII_WOL
bool "IBM EMAC RGMII wake-on-LAN support"
depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST
default y if MY_WONDERFUL_NEW_SOC
Then anyone making an API change that affects this driver can check that
it still complies.
Ben.
> Alistair: The commit name should be different, it's not a PHY you are
> adding, it's a PHY interface (the PHY itself is off chip).
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Jason Cooper @ 2013-11-05 23:00 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: Andrew Lunn, netdev, linux-kernel, Jason Gunthorpe,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <87sivacxcf.fsf@natisbad.org>
On Tue, Nov 05, 2013 at 11:12:00PM +0100, Arnaud Ebalard wrote:
> Hi Jason,
>
> Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
>
> > Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
> > present' made the call to phy_scan optional, if the DT has a link to
> > the phy node.
> >
> > However phy_scan has the side effect of calling phy_addr_set, which
> > writes the phy MDIO address to the ethernet controller. If phy_addr_set
> > is not called, and the bootloader has not set the correct address then
> > the driver will fail to function.
>
> Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
> (Armada 370 based) which I had put on a todo list and temporarily
readynas duo v2?
thx,
Jason.
> workarounded by including a 'ping whatever' call in my u-boot env in
> order to force it to do the init. Without it, I was unable to properly
> use the interface. With your fix, after multiple reboots to test it,
> everything works as expected. So, FWIW:
>
> Tested-by: Arnaud Ebalard <arno@natisbad.org>
>
> Cheers,
>
> a+
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Sebastian Hesselbarth @ 2013-11-05 22:17 UTC (permalink / raw)
To: Arnaud Ebalard, Jason Gunthorpe
Cc: Andrew Lunn, Jason Cooper, linux-kernel, Lennert Buytenhek,
netdev, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <87sivacxcf.fsf@natisbad.org>
On 11/05/2013 11:12 PM, Arnaud Ebalard wrote:
> Hi Jason,
>
> Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
>
>> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
>> present' made the call to phy_scan optional, if the DT has a link to
>> the phy node.
>>
>> However phy_scan has the side effect of calling phy_addr_set, which
>> writes the phy MDIO address to the ethernet controller. If phy_addr_set
>> is not called, and the bootloader has not set the correct address then
>> the driver will fail to function.
>
> Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
> (Armada 370 based) which I had put on a todo list and temporarily
Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta,
are you sure it is (was) related to Jason's fix?
Sebastian
> workarounded by including a 'ping whatever' call in my u-boot env in
> order to force it to do the init. Without it, I was unable to properly
> use the interface. With your fix, after multiple reboots to test it,
> everything works as expected. So, FWIW:
>
> Tested-by: Arnaud Ebalard <arno@natisbad.org>
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Arnaud Ebalard @ 2013-11-05 22:12 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1383611239-14556-1-git-send-email-jgunthorpe@obsidianresearch.com>
Hi Jason,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
> present' made the call to phy_scan optional, if the DT has a link to
> the phy node.
>
> However phy_scan has the side effect of calling phy_addr_set, which
> writes the phy MDIO address to the ethernet controller. If phy_addr_set
> is not called, and the bootloader has not set the correct address then
> the driver will fail to function.
Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
(Armada 370 based) which I had put on a todo list and temporarily
workarounded by including a 'ping whatever' call in my u-boot env in
order to force it to do the init. Without it, I was unable to properly
use the interface. With your fix, after multiple reboots to test it,
everything works as expected. So, FWIW:
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Cheers,
a+
^ permalink raw reply
* Re: [RFC PATCH v2] KVM: PPC: vfio kvm device: support spapr tce
From: Alex Williamson @ 2013-11-05 21:32 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Gleb Natapov, Alexander Graf, kvm-ppc, linux-kernel,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <1383638731-13467-1-git-send-email-aik@ozlabs.ru>
On Tue, 2013-11-05 at 19:05 +1100, Alexey Kardashevskiy wrote:
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> Changes:
> v2:
> * it does not try to introduce a realmode search function.
> Instead, liobn-to-iommu-group lookup is done by VFIO KVM device
> in virtual mode and the result (iommu_group pointer) is cached
> in kvm_arch so the realmode handlers do not use VFIO KVM device for that.
> And the iommu groups get released on KVM termination.
>
> I tried this, seems viable.
>
> Did not I miss anything? Thanks.
A commit message ;)
> ---
> arch/powerpc/include/asm/kvm_host.h | 3 ++
> arch/powerpc/kvm/Kconfig | 1 +
> arch/powerpc/kvm/Makefile | 3 ++
> include/linux/vfio.h | 3 ++
> include/uapi/linux/kvm.h | 1 +
> virt/kvm/vfio.c | 74 +++++++++++++++++++++++++++++++++++++
> 6 files changed, 85 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 48dbe8b..e1163d7 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -293,6 +293,9 @@ struct kvm_arch {
> #ifdef CONFIG_KVM_XICS
> struct kvmppc_xics *xics;
> #endif
> +#ifdef CONFIG_KVM_VFIO
> + struct kvm_vfio *vfio;
> +#endif
> };
>
> /*
> diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
> index 61b3535..d1b7f64 100644
> --- a/arch/powerpc/kvm/Kconfig
> +++ b/arch/powerpc/kvm/Kconfig
> @@ -60,6 +60,7 @@ config KVM_BOOK3S_64
> select KVM_BOOK3S_64_HANDLER
> select KVM
> select SPAPR_TCE_IOMMU
> + select KVM_VFIO
> ---help---
> Support running unmodified book3s_64 and book3s_32 guest kernels
> in virtual machines on book3s_64 host processors.
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index 6646c95..2438d2e 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -87,6 +87,9 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
> kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
> book3s_xics.o
>
> +kvm-book3s_64-objs-$(CONFIG_KVM_VFIO) += \
> + $(KVM)/vfio.o \
> +
> kvm-book3s_64-module-objs := \
> $(KVM)/kvm_main.o \
> $(KVM)/eventfd.o \
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 24579a0..681e19b 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -97,4 +97,7 @@ extern struct vfio_group *vfio_group_get_external_user(struct file *filep);
> extern void vfio_group_put_external_user(struct vfio_group *group);
> extern int vfio_external_user_iommu_id(struct vfio_group *group);
>
> +extern struct iommu_group *vfio_find_group_by_liobn(struct kvm *kvm,
> + unsigned long liobn);
> +
Nope, this doesn't go in vfio.h, it's a function provided by kvm. It
should be named as such too, kvm_vfio_... It also depends on both
CONFIG_KVM_VFIO and CONFIG_SPAPR_TCE_IOMMU and needs stub version
otherwise. Is just _liobn specific enough or does it need a spapr_tce
thrown in to avoid confusion with embedded ppc folks?
> #endif /* VFIO_H */
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 7c1a349..a74ad16 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -847,6 +847,7 @@ struct kvm_device_attr {
> #define KVM_DEV_VFIO_GROUP 1
> #define KVM_DEV_VFIO_GROUP_ADD 1
> #define KVM_DEV_VFIO_GROUP_DEL 2
> +#define KVM_DEV_VFIO_SPAPR_TCE_LIOBN 2
I wonder if it would be better architecturally if this was an attribute
rather than a new group, ex:
#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN 3
It's a mouthful, but we are setting an attribute of a VFIO group, so it
makes sense. kvm_device_attr.addr would then need to point to a struct
containing both the fd and liobn.
Whatever we come up with need a documentation addition in
Documentation/virtual/kvm/devices/vfio.txt.
>
> /*
> * ioctls for VM fds
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index ca4260e..f9271d5 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -22,6 +22,9 @@
> struct kvm_vfio_group {
> struct list_head node;
> struct vfio_group *vfio_group;
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> + uint64_t liobn;
Why is liobn an unsigned long in the exported function but a uint64_t
here?
> +#endif
> };
>
> struct kvm_vfio {
> @@ -188,12 +191,76 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
> return -ENXIO;
> }
>
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> +static int kvm_vfio_set_spapr_tce_liobn(struct kvm_device *dev,
> + long attr, u64 arg)
> +{
> + struct kvm_vfio *kv = dev->private;
> + struct vfio_group *vfio_group;
> + struct kvm_vfio_group *kvg;
> + void __user *argp = (void __user *)arg;
> + struct fd f;
> + int32_t fd;
> + uint64_t liobn = attr;
> +
> + if (get_user(fd, (int32_t __user *)argp))
> + return -EFAULT;
> +
> + f = fdget(fd);
> + if (!f.file)
> + return -EBADF;
> +
> + vfio_group = kvm_vfio_group_get_external_user(f.file);
> + fdput(f);
Not sure why you dropped this from the example of kvm_vfio_set_group:
if (IS_ERR(vfio_group))
return PTR_ERR(vfio_group);
You're also ignoring kv->lock.
> +
> + list_for_each_entry(kvg, &kv->group_list, node) {
> + if (kvg->vfio_group == vfio_group) {
> + WARN_ON(kvg->liobn);
Userspace should not be able to trigger a WARN this easily. Return
EBUSY if it's an error, otherwise let it go.
> + kvg->liobn = liobn;
> + kvm_vfio_group_put_external_user(vfio_group);
> + return 0;
> + }
> + }
> +
> + kvm_vfio_group_put_external_user(vfio_group);
> +
> + return -ENXIO;
> +}
> +
> +struct iommu_group *vfio_find_group_by_liobn(struct kvm *kvm,
> + unsigned long liobn)
As mentioned, kvm_vfio_...
> +{
> + struct kvm_vfio_group *kvg;
> +
> + if (!kvm->arch.vfio)
> + return NULL;
If this is already a slow path you can avoid stashing this pointer and
search kvm->devices for the matching ops struct.
kv->lock...
> +
> + list_for_each_entry(kvg, &kvm->arch.vfio->group_list, node) {
> + if (kvg->liobn == liobn) {
> + int group_id = vfio_external_user_iommu_id(
> + kvg->vfio_group);
> + struct iommu_group *grp =
> + iommu_group_get_by_id(group_id);
nit, ugly line wrapping. Where's the iommu_group_put() done?
> + return grp;
So you've now got an liobn to iommu_group mapping cached away somewhere,
what happens when a group is removed? Would it be invalid for userspace
to re-use the liobn? Do we need a way to invalidate your cached entry
and perhaps do an iommu_group_put()?
This version is actually plausible, so big improvement from v1! Thanks,
Alex
> + }
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(vfio_find_group_by_liobn);
> +#endif
> +
> static int kvm_vfio_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> switch (attr->group) {
> case KVM_DEV_VFIO_GROUP:
> return kvm_vfio_set_group(dev, attr->attr, attr->addr);
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> + case KVM_DEV_VFIO_SPAPR_TCE_LIOBN:
> + return kvm_vfio_set_spapr_tce_liobn(dev, attr->attr,
> + attr->addr);
> +#endif
> }
>
> return -ENXIO;
> @@ -211,6 +278,10 @@ static int kvm_vfio_has_attr(struct kvm_device *dev,
> }
>
> break;
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> + case KVM_DEV_VFIO_SPAPR_TCE_LIOBN:
> + return 0;
> +#endif
> }
>
> return -ENXIO;
> @@ -251,6 +322,9 @@ static int kvm_vfio_create(struct kvm_device *dev, u32 type)
> mutex_init(&kv->lock);
>
> dev->private = kv;
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> + dev->kvm->arch.vfio = kv;
> +#endif
>
> return 0;
> }
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Benjamin Herrenschmidt @ 2013-11-05 19:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Alistair Popple, linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383675404.2868.8.camel@bwh-desktop.uk.level5networks.com>
On Tue, 2013-11-05 at 18:16 +0000, Ben Hutchings wrote:
> On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
> [...]
> > --- a/drivers/net/ethernet/ibm/emac/Kconfig
> > +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> > @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> > bool
> > default n
> >
> > +config IBM_EMAC_RGMII_WOL
> > + bool
> > + default n
> > +
> [...]
>
> So no-one can even build-test this at present!
Patch 7/7 adds the select to the platform, isn't that sufficient ?
It's an SoC bit so there's little point making it generally
selectable by the user.
Alistair: The commit name should be different, it's not a PHY you are
adding, it's a PHY interface (the PHY itself is off chip).
Cheers,
Ben.
^ 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