[PATCH 02/34] New SMBIOS driver for x86 and ia64.

2011-07-18 Thread Prarit Bhargava
...@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

[PATCH] crypto, qat, use generic numa functions

2014-10-07 Thread Prarit Bhargava
...@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

Re: [PATCH] crypto, qat, use generic numa functions

2014-10-08 Thread Prarit Bhargava
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

Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.

2014-10-08 Thread Prarit Bhargava
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

Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.

2014-10-08 Thread Prarit Bhargava
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

Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.

2014-10-08 Thread Prarit Bhargava
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

Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.

2014-10-09 Thread Prarit Bhargava
[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

Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.

2014-10-09 Thread Prarit Bhargava
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

Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.

2014-10-09 Thread Prarit Bhargava
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

Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.

2014-10-10 Thread Prarit Bhargava
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

Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.

2014-10-10 Thread Prarit Bhargava
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

Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration

2014-10-14 Thread Prarit Bhargava
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

Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration

2014-10-14 Thread Prarit Bhargava
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

Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration

2014-10-14 Thread Prarit Bhargava
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

Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration

2014-10-14 Thread Prarit Bhargava
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

Re: [PATCH v2 0/2] crypto: qat - Fix for invalid dma mapping and numa

2014-10-15 Thread Prarit Bhargava
...@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

[PATCH 1/2] hwrng: amd - Revert managed API changes

2017-03-14 Thread Prarit Bhargava
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

[PATCH 2/2] hwrng: geode - Revert managed API changes

2017-03-14 Thread Prarit Bhargava
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

[PATCH 0/2] hwrng: revert managed API changes for amd and geode

2017-03-14 Thread Prarit Bhargava
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