diff for duplicates of <20190510140209.GG9675@localhost.localdomain> diff --git a/a/1.txt b/N1/1.txt index b2c80a5..73849f6 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,7 +1,7 @@ -On Thu, May 09, 2019@11:05:42PM -0700, Kai-Heng Feng wrote: -> Yes, that? what I was told by the NVMe vendor, so all I know is to impose a +On Thu, May 09, 2019 at 11:05:42PM -0700, Kai-Heng Feng wrote: +> Yes, that’ what I was told by the NVMe vendor, so all I know is to impose a > memory barrier. -> If mb() shouldn?t be used here, what?s the correct variant to use in this +> If mb() shouldn’t be used here, what’s the correct variant to use in this > context? I'm afraid the requirement is still not clear to me. AFAIK, all our diff --git a/a/content_digest b/N1/content_digest index 2b4a320..677c500 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -8,15 +8,28 @@ "ref\020190509215409.GD9675@localhost.localdomain\0" "ref\0495d76c66aec41a8bfbbf527820f8eb9@AUSX13MPC101.AMER.DELL.COM\0" "ref\0BC5EB1D0-8718-48B3-ACAB-F7E5571D821D@canonical.com\0" - "From\0kbusch@kernel.org (Keith Busch)\0" - "Subject\0[PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle\0" + "From\0Keith Busch <kbusch@kernel.org>\0" + "Subject\0Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle\0" "Date\0Fri, 10 May 2019 08:02:09 -0600\0" + "To\0Kai-Heng Feng <kai.heng.feng@canonical.com>\0" + "Cc\0Mario.Limonciello@dell.com <Mario.Limonciello@dell.com>" + hch@lst.de <hch@lst.de> + axboe@fb.com <axboe@fb.com> + sagi@grimberg.me <sagi@grimberg.me> + rafael@kernel.org <rafael@kernel.org> + linux-pm@vger.kernel.org <linux-pm@vger.kernel.org> + Wysocki + Rafael J <rafael.j.wysocki@intel.com> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + linux-nvme@lists.infradead.org <linux-nvme@lists.infradead.org> + Busch + " Keith <keith.busch@intel.com>\0" "\00:1\0" "b\0" - "On Thu, May 09, 2019@11:05:42PM -0700, Kai-Heng Feng wrote:\n" - "> Yes, that? what I was told by the NVMe vendor, so all I know is to impose a \n" + "On Thu, May 09, 2019 at 11:05:42PM -0700, Kai-Heng Feng wrote:\n" + "> Yes, that\342\200\231 what I was told by the NVMe vendor, so all I know is to impose a \n" "> memory barrier.\n" - "> If mb() shouldn?t be used here, what?s the correct variant to use in this \n" + "> If mb() shouldn\342\200\231t be used here, what\342\200\231s the correct variant to use in this \n" "> context?\n" "\n" "I'm afraid the requirement is still not clear to me. AFAIK, all our\n" @@ -24,4 +37,4 @@ "CPU and devices. The CPU never accesses HMB memory, so there must be some\n" other reasoning if this barrier is a real requirement for this device. -081f2f79783d81ddf49d3949834438efd56a974f69b710bd91c0e3b9fbfed841 +1ce9301060db3459f43f7183e9a25355d635aaccc0eec5824040e9da53e2a4e0
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.