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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 8 Jan 2016 03:09:33 +0000
From:	"Yu, Xiangliang" <Xiangliang.Yu@....com>
To:	Allen Hubbe <Allen.Hubbe@....com>,
	"jdmason@...zu.us" <jdmason@...zu.us>,
	"dave.jiang@...el.com" <dave.jiang@...el.com>,
	"linux-ntb@...glegroups.com" <linux-ntb@...glegroups.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	SPG_Linux_Kernel <SPG_Linux_Kernel@....com>
Subject: RE: [PATCH V2 0/3] Change notes of V2



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.