Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1302960 > unrolled thread

RE: [PATCH V2 0/3] Change notes of V2

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH V2 0/3] Change notes of V2 "Allen Hubbe" <Allen.Hubbe@emc.com> - 2016-01-06 19:30 +0100
    RE: [PATCH V2 0/3] Change notes of V2 "Yu, Xiangliang" <Xiangliang.Yu@amd.com> - 2016-01-07 04:40 +0100
      RE: [PATCH V2 0/3] Change notes of V2 "Allen Hubbe" <Allen.Hubbe@emc.com> - 2016-01-07 15:50 +0100
        RE: [PATCH V2 0/3] Change notes of V2 "Yu, Xiangliang" <Xiangliang.Yu@amd.com> - 2016-01-08 04:10 +0100

#1302960 — RE: [PATCH V2 0/3] Change notes of V2

From: Xiangliang Yu <Xiangliang.Yu@amd.com>:
> Main changes in V2:
> 1. Fixed compiler warning;
> 2. Add marcro argument of ndev in NTB_READ_REG/NTB_WRITE_REG;
> 3. Add notes for flush and wakeup interfaces;
> 
> Xiangliang Yu (3):
>   NTB: Add AMD PCI-Express NTB driver
>   NTB: Add AMD NTB support in Kconfig and Makefile
>   NTB: Add flush_req and wakeup interface

Could you re-spin these patches as:

Patch 1:
	Only the parts of the driver that fit the current NTB APIs.

Patch 2:
	The new flush_req API, and the related code in the AMD driver.

Patch 3:
	The new wakeup API, and related code in the AMD driver.

In particular, I think we need feedback on #3 from PCI and power management maintainers.

When making #1, please make sure that the patch stands on its own, without any of the code related to #2 or #3 in #1.  Do put the makefile and kconfig changes in #1.

Thanks,
Allen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1303263

PiBGcm9tOiBYaWFuZ2xpYW5nIFl1IDxYaWFuZ2xpYW5nLll1QGFtZC5jb20+Og0KPiA+IE1haW4g
Y2hhbmdlcyBpbiBWMjoNCj4gPiAxLiBGaXhlZCBjb21waWxlciB3YXJuaW5nOw0KPiA+IDIuIEFk
ZCBtYXJjcm8gYXJndW1lbnQgb2YgbmRldiBpbiBOVEJfUkVBRF9SRUcvTlRCX1dSSVRFX1JFRzsg
My4NCj4gQWRkDQo+ID4gbm90ZXMgZm9yIGZsdXNoIGFuZCB3YWtldXAgaW50ZXJmYWNlczsNCj4g
Pg0KPiA+IFhpYW5nbGlhbmcgWXUgKDMpOg0KPiA+ICAgTlRCOiBBZGQgQU1EIFBDSS1FeHByZXNz
IE5UQiBkcml2ZXINCj4gPiAgIE5UQjogQWRkIEFNRCBOVEIgc3VwcG9ydCBpbiBLY29uZmlnIGFu
ZCBNYWtlZmlsZQ0KPiA+ICAgTlRCOiBBZGQgZmx1c2hfcmVxIGFuZCB3YWtldXAgaW50ZXJmYWNl
DQo+IA0KPiBDb3VsZCB5b3UgcmUtc3BpbiB0aGVzZSBwYXRjaGVzIGFzOg0KPiANCj4gUGF0Y2gg
MToNCj4gCU9ubHkgdGhlIHBhcnRzIG9mIHRoZSBkcml2ZXIgdGhhdCBmaXQgdGhlIGN1cnJlbnQg
TlRCIEFQSXMuDQo+IA0KPiBQYXRjaCAyOg0KPiAJVGhlIG5ldyBmbHVzaF9yZXEgQVBJLCBhbmQg
dGhlIHJlbGF0ZWQgY29kZSBpbiB0aGUgQU1EIGRyaXZlci4NCj4gDQo+IFBhdGNoIDM6DQo+IAlU
aGUgbmV3IHdha2V1cCBBUEksIGFuZCByZWxhdGVkIGNvZGUgaW4gdGhlIEFNRCBkcml2ZXIuDQo+
IA0KT2suDQoNCj4gSW4gcGFydGljdWxhciwgSSB0aGluayB3ZSBuZWVkIGZlZWRiYWNrIG9uICMz
IGZyb20gUENJIGFuZCBwb3dlcg0KPiBtYW5hZ2VtZW50IG1haW50YWluZXJzLg0KSSBkb24ndCBn
ZXQgeW91ciBjb25jZXJuLg0KSSB0aGluayB3ZSBjYW4gYWRkIGRldmljZSBhdHRyaWJ1dGUgZmls
ZSB0byBsZXQgYXBwbGljYXRpb24gdG8gdHJpZ2dlciB3YWtldXAgZnVuY3Rpb24sIHRoZW4gTlRC
IGhhcmR3YXJlIHdpbGwgZG8gdGhlIHJlc3QuIE5UQiBkcml2ZXIganVzdCBuZWVkIHRvIGltcGxl
bWVudCBzdXNwZW5kL3Jlc3VtZSBpbnRlcmZhY2Ugb2YgUENJIFBNLg0KDQpBZGQgb25lIG1vcmUg
dGhpbmcsIGRvIHlvdSB0aGluayBOVEIgc2hvdWxkIHN1cHBvcnQgcnVudGltZSBwb3dlciBtYW5h
Z2VtZW50Pw0KDQo+IA0KPiBXaGVuIG1ha2luZyAjMSwgcGxlYXNlIG1ha2Ugc3VyZSB0aGF0IHRo
ZSBwYXRjaCBzdGFuZHMgb24gaXRzIG93biwgd2l0aG91dA0KPiBhbnkgb2YgdGhlIGNvZGUgcmVs
YXRlZCB0byAjMiBvciAjMyBpbiAjMS4gIERvIHB1dCB0aGUgbWFrZWZpbGUgYW5kIGtjb25maWcN
Cj4gY2hhbmdlcyBpbiAjMS4NCk9rLiANCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303622

> > In particular, I think we need feedback on #3 from PCI and power
> > management maintainers.
>
> I don't get your concern.
> I think we can add device attribute file to let application to trigger
> wakeup function, then NTB hardware will do the rest. NTB driver just
> need to implement suspend/resume interface of PCI PM.
> 
> Add one more thing, do you think NTB should support runtime power
> management?
>

I think it is good to make the power management functionality available.  In other words, yes, to your last question.

My concern is that I would like some degree of certainty that it is done right, in harmony with the rest of the kernel.  I don't know what "done right" means in this case, which is why I would like someone else to review it.  A smaller patch with only (and all of) the power management code will have a better chance of being reviewed.

I'm also concerned about the waiting behavior in #2 and #3.  I'm not saying it's wrong.  At least now that behavior is noted in the api documentation; thanks for that.  If a PCI or power management expert has no objection to the waiting behavior in #3, then I would be comfortable with that behavior in #2 as well.

Allen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1304148

Hi ,




> > > In particular, I think we need feedback on #3 from PCI and power
> > > management maintainers.
> >
> > I don't get your concern.
> > I think we can add device attribute file to let application to trigger
> > wakeup function, then NTB hardware will do the rest. NTB driver just
> > need to implement suspend/resume interface of PCI PM.
> >
> > Add one more thing, do you think NTB should support runtime power
> > management?
> >
> 
> I think it is good to make the power management functionality available.  In
> other words, yes, to your last question.

Got it.

> My concern is that I would like some degree of certainty that it is done right,
> in harmony with the rest of the kernel.  I don't know what "done right"
> means in this case, which is why I would like someone else to review it.  A
> smaller patch with only (and all of) the power management code will have a
> better chance of being reviewed.

I think it is ok if following the PM interface and test pass. This version I'll remove 
the PM part and will submit all related PM patch when runtime code is ready.

> I'm also concerned about the waiting behavior in #2 and #3.  I'm not saying
> it's wrong.  At least now that behavior is noted in the api documentation;
> thanks for that.  If a PCI or power management expert has no objection to
> the waiting behavior in #3, then I would be comfortable with that behavior in
> #2 as well.

I also don't like the waiting behavior, but I can't find the asynchronous method to
Let application know the result. And I think #2 is different from #3 because it isn't
related to PM or PCI. Please let me know if you have better choice.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web