The dmatest module parameter 'timeout' is documented as accepting a
-1 to mean "infinite timeout". Howver, an infinite timeout is not
advised, nor possible since the module parameter is an unsigned int,
which won't accept a negative value. Change the parameter
comment to reflect current behavior,
The dmatest module parameter 'timeout' is documented as accepting a
-1 to mean "infinite timeout". Change the parameter to to signed
integer, and check the value to call the appropriate wait_event()
function.
Signed-off-by: Gary R Hook
---
drivers/dma/dmatest.c | 11 ---
1 file
Enablement of AMD's Secure Memory Encryption feature is determined
very early after start_kernel() is entered. Part of this procedure
involves scanning the command line for the parameter 'mem_encrypt'.
To determine intended state, the function sme_enable() uses library
functions
Enablement of AMD's Secure Memory Encryption feature is determined
very early in the boot cycle. Part of this procedure involves scanning
the command line for the paramater 'mem_encrypt'.
To determine intended state, the function sme_enable() uses library
functions cmdline_find_option() and
On 5/7/2018 6:47 PM, kbuild test robot wrote:
Hi Gary,
I imagine these questions have been asked before, so I'll ask for
forgiveness up front.
Thank you for the patch! Yet something to improve:
[auto build test ERROR on iommu/next]
[also build test ERROR on v4.17-rc4 next-20180507]
[if
On 5/7/2018 6:47 PM, kbuild test robot wrote:
Hi Gary,
I imagine these questions have been asked before, so I'll ask for
forgiveness up front.
Thank you for the patch! Yet something to improve:
[auto build test ERROR on iommu/next]
[also build test ERROR on v4.17-rc4 next-20180507]
[if
On 4/18/2018 4:16 PM, Mehta, Sohil wrote:
On Wed, 2018-04-18 at 08:31 +, Yang, Shunyong wrote:
Maybe the original design is to call debugfs_initialized() before
calling debugfs_create_xxx()?
I am unaware of the original design. Someone else would probably have
more context. However,
On 4/18/2018 4:16 PM, Mehta, Sohil wrote:
On Wed, 2018-04-18 at 08:31 +, Yang, Shunyong wrote:
Maybe the original design is to call debugfs_initialized() before
calling debugfs_create_xxx()?
I am unaware of the original design. Someone else would probably have
more context. However,
On 4/17/2018 1:55 PM, Robin Murphy wrote:
On 17/04/18 18:36, Hook, Gary wrote:
On 4/13/2018 7:55 PM, Mehta, Sohil wrote:
On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
+struct dentry *iommu_debugfs_setup(void)
+{
+ if (!debugfs_initialized())
This check is probably not needed
On 4/17/2018 1:55 PM, Robin Murphy wrote:
On 17/04/18 18:36, Hook, Gary wrote:
On 4/13/2018 7:55 PM, Mehta, Sohil wrote:
On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
+struct dentry *iommu_debugfs_setup(void)
+{
+ if (!debugfs_initialized())
This check is probably not needed
On 4/6/2018 9:17 AM, Gary R Hook wrote:
Provide base enablement for using debugfs to expose internal data of
an IOMMU driver. When called, create the /sys/kernel/debug/iommu
directory. Emit a strong warning at boot time to indicate that this
feature is enabled.
This patch adds a top-level
On 4/6/2018 9:17 AM, Gary R Hook wrote:
Provide base enablement for using debugfs to expose internal data of
an IOMMU driver. When called, create the /sys/kernel/debug/iommu
directory. Emit a strong warning at boot time to indicate that this
feature is enabled.
This patch adds a top-level
On 4/16/2018 8:52 PM, Mehta, Sohil wrote:
On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 5eb1121d54b9..0ca250f626d9 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,6 +11,7 @@
On 4/16/2018 8:52 PM, Mehta, Sohil wrote:
On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 5eb1121d54b9..0ca250f626d9 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,6 +11,7 @@
On 4/13/2018 8:08 PM, Mehta, Sohil wrote:
On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
+
+void amd_iommu_debugfs_setup(struct amd_iommu *iommu)
+{
+ char name[MAX_NAME_LEN + 1];
+ struct dentry *d_top;
+
+ if (!debugfs_initialized())
Probably not needed.
Right.
On 4/13/2018 8:08 PM, Mehta, Sohil wrote:
On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
+
+void amd_iommu_debugfs_setup(struct amd_iommu *iommu)
+{
+ char name[MAX_NAME_LEN + 1];
+ struct dentry *d_top;
+
+ if (!debugfs_initialized())
Probably not needed.
Right.
On 4/13/2018 7:55 PM, Mehta, Sohil wrote:
On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
+struct dentry *iommu_debugfs_setup(void)
+{
+ if (!debugfs_initialized())
This check is probably not needed.
Ah, so it isn't. Thank you.
+ return NULL;
+
+ if
On 4/13/2018 7:55 PM, Mehta, Sohil wrote:
On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
+struct dentry *iommu_debugfs_setup(void)
+{
+ if (!debugfs_initialized())
This check is probably not needed.
Ah, so it isn't. Thank you.
+ return NULL;
+
+ if
On 3/2/2018 5:15 PM, Maciej S. Szmigiero wrote:
On 02.03.2018 17:44, Herbert Xu wrote:
On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote:
rsa-pkcs1pad uses a value returned from a RSA implementation max_size
callback as a size of an input buffer passed to the RSA
On 3/2/2018 5:15 PM, Maciej S. Szmigiero wrote:
On 02.03.2018 17:44, Herbert Xu wrote:
On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote:
rsa-pkcs1pad uses a value returned from a RSA implementation max_size
callback as a size of an input buffer passed to the RSA
On 2/14/2018 6:49 AM, Joerg Roedel wrote:
On Tue, Feb 13, 2018 at 02:24:56PM -0500, Hook, Gary wrote:
Without actually running a driver and getting some debug info, I'll just
say that my example compiled, the amd_iommu structure points to a pci_dev
which contains a device, and the two
On 2/14/2018 6:49 AM, Joerg Roedel wrote:
On Tue, Feb 13, 2018 at 02:24:56PM -0500, Hook, Gary wrote:
Without actually running a driver and getting some debug info, I'll just
say that my example compiled, the amd_iommu structure points to a pci_dev
which contains a device, and the two
On 2/13/2018 11:00 AM, Joerg Roedel wrote:
On Tue, Feb 13, 2018 at 10:47:55AM -0500, Hook, Gary wrote:
dev_err(>dev->dev, "ILLEGAL...
I think its more something like iommu->iommu->dev.
Without actually running a driver and getting some debug info, I'll just
sa
On 2/13/2018 11:00 AM, Joerg Roedel wrote:
On Tue, Feb 13, 2018 at 10:47:55AM -0500, Hook, Gary wrote:
dev_err(>dev->dev, "ILLEGAL...
I think its more something like iommu->iommu->dev.
Without actually running a driver and getting some debug info, I'll just
sa
On 2/13/2018 8:22 AM, Joerg Roedel wrote:
On Tue, Jan 30, 2018 at 07:04:27PM -0600, Gary R Hook wrote:
+ dev_err(dev, "ILLEGAL_DEV_TABLE_ENTRY device=%02x:%02x.%x "
+ "address=0x%016llx flags=0x%04x]\n",
+ PCI_BUS_NUM(devid),
On 2/13/2018 8:22 AM, Joerg Roedel wrote:
On Tue, Jan 30, 2018 at 07:04:27PM -0600, Gary R Hook wrote:
+ dev_err(dev, "ILLEGAL_DEV_TABLE_ENTRY device=%02x:%02x.%x "
+ "address=0x%016llx flags=0x%04x]\n",
+ PCI_BUS_NUM(devid),
On 12/13/2017 11:15 AM, Alex Williamson wrote:
On Wed, 13 Dec 2017 10:41:47 -0600
"Hook, Gary" <gh...@amd.com> wrote:
On 12/13/2017 9:58 AM, Alex Williamson wrote:
On Wed, 13 Dec 2017 15:13:55 +0800
Peter Xu <pet...@redhat.com> wrote:
On Tue, Dec 12, 2017 at
On 12/13/2017 11:15 AM, Alex Williamson wrote:
On Wed, 13 Dec 2017 10:41:47 -0600
"Hook, Gary" wrote:
On 12/13/2017 9:58 AM, Alex Williamson wrote:
On Wed, 13 Dec 2017 15:13:55 +0800
Peter Xu wrote:
On Tue, Dec 12, 2017 at 03:43:08PM -0700, Alex Williamson wrote:
[...]
On 12/13/2017 9:58 AM, Alex Williamson wrote:
On Wed, 13 Dec 2017 15:13:55 +0800
Peter Xu wrote:
On Tue, Dec 12, 2017 at 03:43:08PM -0700, Alex Williamson wrote:
[...]
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 9a7ffd13c7f0..87888b102057 100644
---
On 12/13/2017 9:58 AM, Alex Williamson wrote:
On Wed, 13 Dec 2017 15:13:55 +0800
Peter Xu wrote:
On Tue, Dec 12, 2017 at 03:43:08PM -0700, Alex Williamson wrote:
[...]
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 9a7ffd13c7f0..87888b102057 100644
---
30 matches
Mail list logo