On Wed, May 20, 2015 at 11:27:54AM +0200, Arnd Bergmann wrote:
On Wednesday 20 May 2015 10:24:15 Catalin Marinas wrote:
On Sat, May 16, 2015 at 01:59:00AM +0200, Rafael J. Wysocki wrote:
On Friday, May 15, 2015 04:23:11 PM Suravee Suthikulpanit wrote:
+/**
+ * pci_dma_configure -
On 5/20/2015 5:03 AM, Catalin Marinas wrote:
On Fri, May 15, 2015 at 04:23:10PM -0500, Suravee Suthikulpanit wrote:
From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
object to be specified for DMA-cabpable
On Wednesday 20 May 2015 06:52:03 Suravee Suthikulanit wrote:
On 5/20/2015 5:01 AM, Catalin Marinas wrote:
On Fri, May 15, 2015 at 04:23:09PM -0500, Suravee Suthikulpanit wrote:
+static inline bool acpi_dma_is_supported(struct acpi_device *adev)
+{
+/**
+ * Currently, we mainly
On Fri, May 15, 2015 at 04:23:09PM -0500, Suravee Suthikulpanit wrote:
+static inline bool acpi_dma_is_supported(struct acpi_device *adev)
+{
+ /**
+ * Currently, we mainly support _CCA=1 (i.e. is_coherent=1)
+ * This should be equivalent to specifyig dma-coherent for
+ *
On 20 May 2015 at 16:59, Theodore Ts'o ty...@mit.edu wrote:
On Wed, May 20, 2015 at 09:21:20AM +0200, Steffen Klassert wrote:
The current pcrypt version is used just for IPsec because it supports
only AEAD type algorithms and does not support request backlog. But
I have patches to support
On Wed, May 20, 2015 at 05:30:14PM +0200, Ard Biesheuvel wrote:
However, it's quite a can of worms you're opening here. Speed is
easily quantified, and it may even be feasible to introduce some kind
of boottime benchmark to select the fastest implementation available
(like already exists for
Am Mittwoch, 20. Mai 2015, 11:06:42 schrieb Theodore Ts'o:
Hi Theodore,
As a side note to this discussion, may I ask why entropy_total is used for
checking against the threshold value and not entropy_count?
The reason for my question is the following: until a DRNG (in the worst case,
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen andreas.stef...@strongswan.org
CC: Theodore Ts'o ty...@mit.edu
CC: Sandy Harris sandyinch...@gmail.com
Signed-off-by:
On Wed, May 20, 2015 at 07:00:25AM -0500, Suravee Suthikulanit wrote:
On 5/20/2015 4:34 AM, Catalin Marinas wrote:
We have a dummy of_dma_configure() already when !CONFIG_OF, otherwise
we would need #ifndef here. I already replied, I think for other
architectures we need this check to avoid a
On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
@@ -1487,6 +1514,7 @@ unlock:
*/
static int drbg_uninstantiate(struct drbg_state *drbg)
{
+ cancel_work_sync(drbg-seed_work);
This will just block until the work is done, i.e., until the
pool is ready. It's no
On 5/20/2015 5:28 AM, Will Deacon wrote:
On Fri, May 15, 2015 at 10:23:12PM +0100, Suravee Suthikulpanit wrote:
Currently, device drivers, which support both OF and ACPI,
need to call two separate APIs, of_dma_is_coherent() and
acpi_dma_is_coherent()) to determine device coherency attribute.
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen andreas.stef...@strongswan.org
CC: Theodore Ts'o ty...@mit.edu
CC: Sandy Harris sandyinch...@gmail.com
Signed-off-by:
Am Mittwoch, 20. Mai 2015, 21:44:46 schrieb Stephan Mueller:
Hi,
+int get_blocking_random_bytes(void *buf, int nbytes)
+{
+ int rc;
Sorry, I should be more carefully here: the rc should be initialized to 0 :-(
--
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe
Hi,
as of now, the DRBG is only seeded from get_random_bytes. In various
circumstances, the nonblocking_pool behind get_random_bytes may not be fully
seeded from hardware events at the time the DRBG requires to be seeded.
Based on the discussion in [1], the DRBG seeding is updated such that it
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the
On Wed, May 20, 2015 at 07:44:39PM +0200, Stephan Mueller wrote:
+ if (unlikely(nonblocking_pool.initialized == 0)) {
+ do {
+ rc = wait_event_interruptible(urandom_init_wait,
+ nonblocking_pool.initialized);
+
Am Mittwoch, 20. Mai 2015, 20:49:45 schrieb Stephan Mueller:
Hi Herbert,
This is just a convoluted way of doing an uninterruptible sleep.
Either make it uninterruptible or allow the function to return
an error.
Sorry, I overlooked the availability of wait_event. I was looking for it
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen andreas.stef...@strongswan.org
CC: Theodore Ts'o ty...@mit.edu
CC: Sandy Harris sandyinch...@gmail.com
Signed-off-by:
Am Donnerstag, 21. Mai 2015, 02:45:35 schrieb Herbert Xu:
Hi Herbert,
On Wed, May 20, 2015 at 07:44:39PM +0200, Stephan Mueller wrote:
+ if (unlikely(nonblocking_pool.initialized == 0)) {
+ do {
+ rc = wait_event_interruptible(urandom_init_wait,
+
Hi,
as of now, the DRBG is only seeded from get_random_bytes. In various
circumstances, the nonblocking_pool behind get_random_bytes may not be fully
seeded from hardware events at the time the DRBG requires to be seeded.
Based on the discussion in [1], the DRBG seeding is updated such that it
Currently, device drivers, which support both OF and ACPI,
need to call two separate APIs, of_dma_is_coherent() and
acpi_dma_is_coherent()) to determine device coherency attribute.
This patch simplifies this process by introducing a new device
property API, device_dma_is_coherent(), which calls
Currently, the driver has separate logic to determine device coherency
for DT vs ACPI. This patch simplifies the code with a call to
device_dma_is_coherent().
Signed-off-by: Tom Lendacky thomas.lenda...@amd.com
Signed-off-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
---
This patch series introduce support for _CCA object, which is currently
used mainly by ARM64 platform to specify DMA coherency attribute for
devices when booting with ACPI.
A copy of ACPIv6 can be found here:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
This patch also
Currently, amd-xgbe driver has separate logic to determine device
coherency for DT vs. ACPI. This patch simplifies the code with
a call to device_dma_is_coherent().
Signed-off-by: Tom Lendacky thomas.lenda...@amd.com
Signed-off-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
---
This patch implements support for ACPI _CCA object, which is introduced in
ACPIv5.1, can be used for specifying device DMA coherency attribute.
The parsing logic traverses device namespace to parse coherency
information, and stores it in acpi_device_flags. Then uses it to call
From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
object to be specified for DMA-cabpable devices. Therefore, this patch
specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
In addition, to handle the case when _CCA is
34 matches
Mail list logo
