ter the first load of the driver.
Revert the changes made by e9afc746299d ("hwrng: geode - Use linux/io.h
instead of asm/io.h").
Signed-off-by: Prarit Bhargava <pra...@redhat.com>
Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API")
Cc: Matt Mackall
and region after the first load of the driver.
Revert the changes made by 31b2a73c9c5f ("hwrng: amd - Migrate to managed
API").
Signed-off-by: Prarit Bhargava <pra...@redhat.com>
Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API").
Cc: Matt Mack
grate to managed API"), and 6e9b5e76882c
("hwrng: geode - Migrate to managed API").
Signed-off-by: Prarit Bhargava <pra...@redhat.com>
Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API").
Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API
...@redhat.com
Thanks Nik :)
Reviewed-by: Prarit Bhargava pra...@redhat.com
P.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/13/2014 09:24 PM, Tadeusz Struk wrote:
snip
- node = adf_get_dev_node_id(pdev);
- accel_dev = kzalloc_node(sizeof(*accel_dev), GFP_KERNEL, node);
+ if (num_possible_nodes() 1 dev_to_node(pdev-dev) 0) {
+ /* If the accelerator is connected to a node with no
On 10/14/2014 10:50 AM, Tadeusz Struk wrote:
On 10/14/2014 03:53 AM, Prarit Bhargava wrote:
- node = adf_get_dev_node_id(pdev);
- accel_dev = kzalloc_node(sizeof(*accel_dev), GFP_KERNEL, node);
+ if (num_possible_nodes() 1 dev_to_node(pdev-dev) 0
On 10/14/2014 01:18 PM, Tadeusz Struk wrote:
On 10/14/2014 08:41 AM, Prarit Bhargava wrote:
Oh, that's a really good point. But can you at least change the message to
do a
FW_BUG and dump the node information? That would be useful for debugging.
But this not always will be a FW_BUG
On 10/14/2014 01:27 PM, Prarit Bhargava wrote:
On 10/14/2014 01:18 PM, Tadeusz Struk wrote:
On 10/14/2014 08:41 AM, Prarit Bhargava wrote:
Oh, that's a really good point. But can you at least change the message to
do a
FW_BUG and dump the node information? That would be useful
On 10/09/2014 07:12 PM, Tadeusz Struk wrote:
On 10/09/2014 02:42 PM, Prarit Bhargava wrote:
I don't think cpu hotplug matters here. This is one (probe) time
determination if the configuration is optimal or not and if it makes
sense to use this accelerator or not.
It absolutely matters
On 10/10/2014 09:25 AM, Tadeusz Struk wrote:
On 10/10/2014 04:23 AM, Prarit Bhargava wrote:
Sure, but I still think that we are safe here.
No, you're not. Dropping a single CPU changes num_online_cpus(), which
results in
static uint8_t adf_get_dev_node_id(struct pci_dev *pdev
[sorry ... accidentally hit reply instead of reply all ... resending to
everyone]
On 10/08/2014 03:25 PM, Tadeusz Struk wrote:
On 10/08/2014 12:01 PM, Prarit Bhargava wrote:
No that isn't correct. dev_to_node() will return the node the device is
connected to.
include/linux/device.h
On 10/09/2014 12:14 PM, Tadeusz Struk wrote:
On 10/09/2014 04:23 AM, Prarit Bhargava wrote:
int numa_node; /* NUMA node this device is close to */
...
That's just bad english. The numa node value (for pci devices) is
read from the ACPI tables on the system and represents the node
On 10/09/2014 03:55 PM, Tadeusz Struk wrote:
On 10/09/2014 10:32 AM, Prarit Bhargava wrote:
This calculation is sole for multi-socket configuration. This is why is
was introduced and what it was tested for.
There is no point discussing NUMA for single-socket configuration.
Single socket
On 10/08/2014 11:50 AM, Tadeusz Struk wrote:
Hi Prarit,
On 10/07/2014 05:12 PM, Prarit Bhargava wrote:
The method in which the qat code determines the numa node for memory
allocations is a bit clunky. On 2 socket, single node systems it is
possible that adf_get_dev_node_id() returns node 1
On 10/08/2014 01:38 PM, Tadeusz Struk wrote:
In a system with NUMA configuration we want to enforce that the accelerator is
connected to a node with memory to avoid cross QPI memory transaction.
Otherwise there is no point in using the accelerator as the encryption in
software will be
On 10/08/2014 02:11 PM, Tadeusz Struk wrote:
On 10/08/2014 10:57 AM, Prarit Bhargava wrote:
node = adf_get_dev_node_id(pdev);
^^^ I don't think you should ever make this call. IMO it is wrong to do it
that
way. Just stick with
node = dev_to_node(pdev-dev)
as the line below
On 10/08/2014 02:57 PM, Tadeusz Struk wrote:
On 10/08/2014 11:35 AM, Prarit Bhargava wrote:
But then how do I know which node I'm physically connected to?
The pci_dev maps to the bus which maps to a numa node. The pci_dev's numa
value
is copied directly from the bus (or busses depending
...@davemloft.net
Cc: Bruce Allan bruce.w.al...@intel.com
Cc: Prarit Bhargava pra...@redhat.com
Cc: John Griffin john.grif...@intel.com
Cc: qat-li...@intel.com
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Prarit Bhargava pra...@redhat.com
---
drivers/crypto/qat/qat_common/adf_accel_devices.h |2 +-
drivers
...@blackfin.uclinux.org
Cc: linux-watch...@vger.kernel.org
Cc: grant.lik...@secretlab.ca
Cc: d...@debian.org
Cc: rpur...@rpsys.net
Cc: eric.p...@tremplin-utc.net
Cc: abe...@mit.edu
Cc: john...@2ka.mipt.ru
Signed-off-by: Prarit Bhargava pra...@redhat.com
---
Documentation/ABI/obsolete/sysfs-dmi | 40
19 matches
Mail list logo