[PATCH v2 4/8] cpupower: Remove unused pscur variable.

that the MSR_AMD_PSTATE_STATUS MSR is present. Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils/helpers/amd.c |9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/tools/power/cpupower/utils/helpers/amd.c b/tools/power/cpupower/utils/helpers/amd.c index 8b69c7ff639a

[PATCH v2 6/8] cpupower: Condense pstate enabled bit checks in decode_pstates()

The enabled bit (bit 63) is common for all families so we can remove the multiple enabled checks based on family and have a common check for HW pstate enabled. Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils/helpers/amd.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions

[PATCH v2 3/8] cpupower: Add CPUPOWER_CAP_AMD_HW_PSTATE cpuid caps flag

ted on family 14h. This is intended to reduce family checks in the main code paths. Signed-off-by: Nathan Fontenot --- Updates for v2: Update and add back previously removed comment. --- tools/power/cpupower/utils/helpers/amd.c |9 - tools/power/cpupower/utils/helpers/cpuid.c |

[PATCH v2 5/8] cpupower: Update family checks when decoding HW pstates

The family checks in get_cof() and get_did() need to use the correct MSR format depending on the family. Add a cpupower capability for using the pstatedef (family 17h and newer) to control this instead of direct family checks. Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils

[PATCH v2 7/8] cpupower: Remove family arg to decode_pstates()

The decode_pstates() routine no longer uses the CPU family and the caleed routines (get_cof() and get_did()) can grab the family from the global cpupower_cpu_info struct. These update removes passing the family arg to all these routines. Signed-off-by: Nathan Fontenot --- tools/power/cpupower

[PATCH v2 8/8] cpupower: Add cpuid cap flag for MSR_AMD_HWCR support

Remove the family check for accessing the MSR_AMD_HWCR MSR and replace it with a cpupower cap flag. This update also allows for the removal of the local cpupower_cpu_info variable in cpufreq_has_boost_support() since we no longer need it to check the family. Signed-off-by: Nathan Fontenot

[PATCH v2 2/8] cpupower: Correct macro name for CPB caps flag

From: Robert Richter The name is Core Performance Boost (CPB) for the cpuid flag. Correct cpuid caps flag to use this name (instead of CBP). Signed-off-by: Robert Richter Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils/helpers/cpuid.c |2 +- tools/power/cpupower/utils

[PATCH v2 0/8] cpupower: Updates and cleanup to support AMD Family 0x19

d.c | 65 -- tools/power/cpupower/utils/helpers/cpuid.c | 20 +++- tools/power/cpupower/utils/helpers/helpers.h | 14 +++--- tools/power/cpupower/utils/helpers/misc.c|9 +--- 5 files changed, 57 insertions(+), 54 deletions(-) -- Nathan Fontenot

[PATCH v2 1/8] cpupower: Update msr_pstate union struct naming

ing. There are no functional changes as part of this update. 1: AMD Processor Programming Reference (PPR) and BIOS and Kernel Developer's Guide (BKDG) available at: http://developer.amd.com/resources/developer-guides-manuals Signed-off-by: Nathan Fontenot --- Updates for v2: Add links to PPR/B

[PATCH 4/8] cpupower: Remove unused pscur variable.

that the MSR_AMD_PSTATE_STATUS MSR is present. Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils/helpers/amd.c |9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/tools/power/cpupower/utils/helpers/amd.c b/tools/power/cpupower/utils/helpers/amd.c index 496844a20fe2

[PATCH 8/8] cpupower: Add cpuid cap flag for MSR_AMD_HWCR support

Remove the family check for accessing the MSR_AMD_HWCR MSR and replace it with a cpupower cap flag. This update also allows for the removal of the local cpupower_cpu_info variable in cpufreq_has_boost_support() since we no longer need it to check the family. Signed-off-by: Nathan Fontenot

[PATCH 7/8] cpupower: Remove family arg to decode_pstates()

The decode_pstates() routine no longer uses the CPU family and the caleed routines (get_cof() and get_did()) can grab the family from the global cpupower_cpu_info struct. These update removes passing the family arg to all these routines. Signed-off-by: Nathan Fontenot --- tools/power/cpupower

[PATCH 6/8] cpupower: Condense pstate enabled bit checks in decode_pstates()

The enabled bit (bit 63) is common for all families so we can remove the multiple enabled checks based on family and have a common check for HW pstate enabled. Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils/helpers/amd.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions

[PATCH 2/8] cpupower: Correct macro name for CPB caps flag

From: Robert Richter The name is Core Performance Boost (CPB) for the cpuid flag. Correct cpuid caps flag to use this name (instead of CBP). Signed-off-by: Robert Richter Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils/helpers/cpuid.c |2 +- tools/power/cpupower/utils

[PATCH 5/8] cpupower: Update family checks when decoding HW pstates

The family checks in get_cof() and get_did() need to use the correct MSR format depending on the family. Add a cpupower capability for using the pstatedef (family 17h and newer) to control this instead of direct family checks. Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils

[PATCH 3/8] cpupower: Add CPUPOWER_CAP_AMD_HW_PSTATE cpuid caps flag

ted on family 14h. This is intended to reduce family checks in the main code paths. Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils/helpers/amd.c |6 +- tools/power/cpupower/utils/helpers/cpuid.c | 12 +--- tools/power/cpupower/utils/helpers/helpers.h |1 +

[PATCH 0/8] cpupower: Updates and cleanup to support AMD Family 0x19

ing patches are cleanups to remove unneeded extra enabled bit checking, remove passing no longer used variables, and remove unused variables in decode_pstates(). --- Nathan Fontenot (7): cpupower: Update msr_pstate union struct naming cpupower: Add CPUPOWER_CAP_AMD_HW_PSTATE cpuid caps f

[PATCH 1/8] cpupower: Update msr_pstate union struct naming

ing. There are no functional changes as part of this update. Signed-off-by: Nathan Fontenot --- tools/power/cpupower/utils/helpers/amd.c | 26 ++ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/tools/power/cpupower/utils/helpers/amd.c b/tools/power/cpupower/ut

[tip: sched/core] x86, sched: Calculate frequency invariance for AMD systems

The following commit has been merged into the sched/core branch of tip: Commit-ID: 41ea667227bad5c247d76e6605054e96e4d95f51 Gitweb: https://git.kernel.org/tip/41ea667227bad5c247d76e6605054e96e4d95f51 Author:Nathan Fontenot AuthorDate:Thu, 12 Nov 2020 19:26:12 +01:00

[tip: sched/core] x86, sched: Calculate frequency invariance for AMD systems

The following commit has been merged into the sched/core branch of tip: Commit-ID: 0edb0fb35fa687e633322d23e5f44b7cfd21a5c5 Gitweb: https://git.kernel.org/tip/0edb0fb35fa687e633322d23e5f44b7cfd21a5c5 Author:Nathan Fontenot AuthorDate:Thu, 12 Nov 2020 19:26:12 +01:00

Re: [PATCH 1/2] powerpc/nodes: Ensure enough nodes avail for operations

On 10/17/2017 12:22 PM, Michael Bringmann wrote: > > > On 10/17/2017 12:02 PM, Nathan Fontenot wrote: >> On 10/17/2017 11:14 AM, Michael Bringmann wrote: >>> See below. >>> >>> On 10/16/2017 07:33 AM, Michael Ellerman wrote: >>>&

Re: [PATCH 1/2] powerpc/nodes: Ensure enough nodes avail for operations

On 10/17/2017 12:22 PM, Michael Bringmann wrote: > > > On 10/17/2017 12:02 PM, Nathan Fontenot wrote: >> On 10/17/2017 11:14 AM, Michael Bringmann wrote: >>> See below. >>> >>> On 10/16/2017 07:33 AM, Michael Ellerman wrote: >>>> Michael B

Re: [PATCH 1/2] powerpc/nodes: Ensure enough nodes avail for operations

On 10/17/2017 11:14 AM, Michael Bringmann wrote: > See below. > > On 10/16/2017 07:33 AM, Michael Ellerman wrote: >> Michael Bringmann writes: >> >>> powerpc/nodes: On systems like PowerPC which allow 'hot-add' of CPU >> >> This is a powerpc-only patch, so saying

Re: [PATCH 1/2] powerpc/nodes: Ensure enough nodes avail for operations

On 10/17/2017 11:14 AM, Michael Bringmann wrote: > See below. > > On 10/16/2017 07:33 AM, Michael Ellerman wrote: >> Michael Bringmann writes: >> >>> powerpc/nodes: On systems like PowerPC which allow 'hot-add' of CPU >> >> This is a powerpc-only patch, so saying "systems like PowerPC" is >>

Re: [PATCH V13 4/4] powerpc/vphn: Fix numa update end-loop bug

On 09/06/2017 05:03 PM, Michael Bringmann wrote: > > > On 09/06/2017 09:45 AM, Nathan Fontenot wrote: >> On 09/01/2017 10:48 AM, Michael Bringmann wrote: >>> powerpc/vphn: On Power systems with shared configurations of CPUs >>> and memory, there are some issues w

Re: [PATCH V13 4/4] powerpc/vphn: Fix numa update end-loop bug

On 09/06/2017 05:03 PM, Michael Bringmann wrote: > > > On 09/06/2017 09:45 AM, Nathan Fontenot wrote: >> On 09/01/2017 10:48 AM, Michael Bringmann wrote: >>> powerpc/vphn: On Power systems with shared configurations of CPUs >>> and memory, there are some issues w

Re: [PATCH V13 4/4] powerpc/vphn: Fix numa update end-loop bug

On 09/01/2017 10:48 AM, Michael Bringmann wrote: > powerpc/vphn: On Power systems with shared configurations of CPUs > and memory, there are some issues with the association of additional > CPUs and memory to nodes when hot-adding resources. This patch > fixes an end-of-updates processing problem

Re: [PATCH V13 4/4] powerpc/vphn: Fix numa update end-loop bug

On 09/01/2017 10:48 AM, Michael Bringmann wrote: > powerpc/vphn: On Power systems with shared configurations of CPUs > and memory, there are some issues with the association of additional > CPUs and memory to nodes when hot-adding resources. This patch > fixes an end-of-updates processing problem

Re: [PATCH V13 3/4] powerpc/hotplug: Improve responsiveness of hotplug change

On 09/01/2017 10:48 AM, Michael Bringmann wrote: > powerpc/hotplug: On Power systems with shared configurations of CPUs > and memory, there are some issues with the association of additional > CPUs and memory to nodes when hot-adding resources. During hotplug > CPU operations, this patch resets

Re: [PATCH V13 3/4] powerpc/hotplug: Improve responsiveness of hotplug change

On 09/01/2017 10:48 AM, Michael Bringmann wrote: > powerpc/hotplug: On Power systems with shared configurations of CPUs > and memory, there are some issues with the association of additional > CPUs and memory to nodes when hot-adding resources. During hotplug > CPU operations, this patch resets

Re: [PATCH V13 2/4] powerpc/vphn: Improve recognition of PRRN/VPHN

On 09/01/2017 10:48 AM, Michael Bringmann wrote: > powerpc/vphn: On Power systems with shared configurations of CPUs > and memory, there are some issues with the association of additional > CPUs and memory to nodes when hot-adding resources. This patch > updates the initialization checks to

Re: [PATCH V13 2/4] powerpc/vphn: Improve recognition of PRRN/VPHN

On 09/01/2017 10:48 AM, Michael Bringmann wrote: > powerpc/vphn: On Power systems with shared configurations of CPUs > and memory, there are some issues with the association of additional > CPUs and memory to nodes when hot-adding resources. This patch > updates the initialization checks to

Re: [PATCH V13 1/4] powerpc/vphn: Update CPU topology when VPHN enabled

On 09/01/2017 10:48 AM, Michael Bringmann wrote: > powerpc/vphn: On Power systems with shared configurations of CPUs > and memory, there are some issues with the association of additional > CPUs and memory to nodes when hot-adding resources. This patch > corrects the currently broken capability

Re: [PATCH V13 1/4] powerpc/vphn: Update CPU topology when VPHN enabled

On 09/01/2017 10:48 AM, Michael Bringmann wrote: > powerpc/vphn: On Power systems with shared configurations of CPUs > and memory, there are some issues with the association of additional > CPUs and memory to nodes when hot-adding resources. This patch > corrects the currently broken capability

Re: [PATCH V10 1/2] powerpc/numa: Update CPU topology when VPHN enabled

On 08/24/2017 05:07 PM, Michael Bringmann wrote: > > powerpc/numa: Correct the currently broken capability to set the > topology for shared CPUs in LPARs. At boot time for shared CPU > lpars, the topology for each shared CPU is set to node zero, however, > this is now updated correctly using the

Re: [PATCH V10 1/2] powerpc/numa: Update CPU topology when VPHN enabled

On 08/24/2017 05:07 PM, Michael Bringmann wrote: > > powerpc/numa: Correct the currently broken capability to set the > topology for shared CPUs in LPARs. At boot time for shared CPU > lpars, the topology for each shared CPU is set to node zero, however, > this is now updated correctly using the

Re: [PATCH V9 2/2] powerpc/nodes: Ensure enough nodes avail for operations

.vnet.ibm.com> > Cc: John Allen <jal...@linux.vnet.ibm.com> > Cc: Nathan Fontenot <nf...@linux.vnet.ibm.com> > Subject: [PATCH V9 2/2] powerpc/nodes: Ensure enough nodes avail for > operations > > powerpc/nodes: On systems like PowerPC which allow 'hot-a

Re: [PATCH V9 2/2] powerpc/nodes: Ensure enough nodes avail for operations

On 08/21/2017 04:44 PM, Michael Bringmann wrote: > To: linuxppc-...@lists.ozlabs.org > > From: Michael Bringmann > > To: linux-kernel@vger.kernel.org > Cc: Michael Ellerman > Cc: Michael Bringmann > Cc: John Allen > Cc: Nathan Fontenot > Subject: [PATCH V9 2/2

Re: [PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN enabled

On 08/23/2017 06:41 AM, Michael Ellerman wrote: > Michael Bringmann writes: > >> powerpc/numa: Correct the currently broken capability to set the >> topology for shared CPUs in LPARs. At boot time for shared CPU >> lpars, the topology for each shared CPU is set to node

Re: [PATCH V9 1/2] powerpc/numa: Update CPU topology when VPHN enabled

On 08/23/2017 06:41 AM, Michael Ellerman wrote: > Michael Bringmann writes: > >> powerpc/numa: Correct the currently broken capability to set the >> topology for shared CPUs in LPARs. At boot time for shared CPU >> lpars, the topology for each shared CPU is set to node zero, however, >> this is

Re: [PATCH v6] workqueue: Fix edge cases for calc of pool's cpumask

On 07/27/2017 01:15 PM, Michael Bringmann wrote: > > On NUMA systems with dynamic processors, the content of the cpumask > may change over time. As new processors are added via DLPAR operations, > workqueues are created for them. Depending upon the order in which CPUs > are added/removed, we

Re: [PATCH v6] workqueue: Fix edge cases for calc of pool's cpumask

On 07/27/2017 01:15 PM, Michael Bringmann wrote: > > On NUMA systems with dynamic processors, the content of the cpumask > may change over time. As new processors are added via DLPAR operations, > workqueues are created for them. Depending upon the order in which CPUs > are added/removed, we

Re: [PATCH V4 1/2] powerpc/numa: Update CPU topology when VPHN enabled

On 05/26/2017 04:29 PM, Michael Bringmann wrote: > > powerpc/numa: Correct the currently broken capability to set the > topology for shared CPUs in LPARs. At boot time for shared CPU > lpars, the topology for each shared CPU is set to node zero, however, > this is now updated correctly using the

Re: [PATCH V4 1/2] powerpc/numa: Update CPU topology when VPHN enabled

On 05/26/2017 04:29 PM, Michael Bringmann wrote: > > powerpc/numa: Correct the currently broken capability to set the > topology for shared CPUs in LPARs. At boot time for shared CPU > lpars, the topology for each shared CPU is set to node zero, however, > this is now updated correctly using the

Re: [PATCH] powerpc/hotplug-mem: Fix aa_index match bug for hotplug

On 05/30/2017 06:41 AM, Michael Ellerman wrote: > Michael Bringmann writes: > >> When adding or removing memory, the aa_index (affinity value) for the >> memblock must also be converted to match the endianness of the rest >> of the 'ibm,dynamic-memory' property.

Re: [PATCH] powerpc/hotplug-mem: Fix aa_index match bug for hotplug

On 05/30/2017 06:41 AM, Michael Ellerman wrote: > Michael Bringmann writes: > >> When adding or removing memory, the aa_index (affinity value) for the >> memblock must also be converted to match the endianness of the rest >> of the 'ibm,dynamic-memory' property. Otherwise, subsequent retrieval

Re: [PATCH] powerpc/pseries: fix spelling mistake: "Attemping" -> "Attempting"

On 10/24/2016 05:02 PM, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com> > > trivial fix to spelling mistake in pr_debug message > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Nathan Fontenot <nf...@linux.vnet.i

Re: [PATCH] powerpc/pseries: fix spelling mistake: "Attemping" -> "Attempting"

On 10/24/2016 05:02 PM, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in pr_debug message > > Signed-off-by: Colin Ian King Reviewed-by: Nathan Fontenot > --- > arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 +- > 1 file changed, 1

Re: [PATCH 0/4] powerpc/mm: movable hotplug memory nodes

On 08/10/2016 05:30 AM, Michael Ellerman wrote: > Reza Arbab writes: > >> These changes enable onlining memory into ZONE_MOVABLE on power, and the >> creation of discrete nodes of movable memory. >> >> Node hotplug is not supported on power [1]. > > But maybe it should

Re: [PATCH 0/4] powerpc/mm: movable hotplug memory nodes

On 08/10/2016 05:30 AM, Michael Ellerman wrote: > Reza Arbab writes: > >> These changes enable onlining memory into ZONE_MOVABLE on power, and the >> creation of discrete nodes of movable memory. >> >> Node hotplug is not supported on power [1]. > > But maybe it should be? > Yes, it should be

Re: [Patch v2] rpaphp: fix slot registration for multiple slots under a PHB

[ 38.482356] rpaphp: Slot [C3] registered > [ 38.482495] rpaphp: Slot [C4] registered > > Signed-off-by: Tyrel Datwyler <tyr...@linux.vnet.ibm.com> Reviewed-by: Nathan Fontenot <nf...@linux.vnet.ibm.com> > --- > > Changes in v2: corrected ibm,my-drc-index property name

Re: [Patch v2] rpaphp: fix slot registration for multiple slots under a PHB

[ 38.482356] rpaphp: Slot [C3] registered > [ 38.482495] rpaphp: Slot [C4] registered > > Signed-off-by: Tyrel Datwyler Reviewed-by: Nathan Fontenot > --- > > Changes in v2: corrected ibm,my-drc-index property name > > --- > drivers/pci/hotplug/rpaphp_slot.c | 17 ++

Re: [PATCH] rpaphp: fix slot registration for multiple slots under a PHB

On 07/08/2016 06:19 PM, Tyrel Datwyler wrote: > PowerVM seems to only ever provide a single hotplug slot per PHB. > The under lying slot hotplug registration code assumed multiple slots, > but the actual implementation is broken for multiple slots. This went > unnoticed for years due to the nature

Re: [PATCH] rpaphp: fix slot registration for multiple slots under a PHB

On 07/08/2016 06:19 PM, Tyrel Datwyler wrote: > PowerVM seems to only ever provide a single hotplug slot per PHB. > The under lying slot hotplug registration code assumed multiple slots, > but the actual implementation is broken for multiple slots. This went > unnoticed for years due to the nature

Re: [PATCH 2/3] powerpc: make kernel/nvram_64.c explicitly non-modular

le already has that. > > We delete the MODULE_LICENSE tag since that information is already > contained at the top of the file in the comments. > > Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Cc: Paul Mackerras <pau...@samba.org> > Cc: Michael Ellerman

Re: [PATCH 2/3] powerpc: make kernel/nvram_64.c explicitly non-modular

le already has that. > > We delete the MODULE_LICENSE tag since that information is already > contained at the top of the file in the comments. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Hari Bathini > Cc: Nathan Fontenot &

Re: [PATCH] powerpc/nvram: Fix a memory leak in err path

On 12/09/2015 04:00 AM, xinhui wrote: > > If kmemdup fails, We need kfree *buff* first then return -ENOMEM. > Otherwise there is a memory leak. > > Signed-off-by: Pan Xinhui Reviewed-by: Nathan Fontenot > --- > arch/powerpc/kernel/nvram_64.c | 2 +- > 1 file ch

Re: [PATCH] powerpc/nvram: Fix a memory leak in err path

On 12/09/2015 04:00 AM, xinhui wrote: > > If kmemdup fails, We need kfree *buff* first then return -ENOMEM. > Otherwise there is a memory leak. > > Signed-off-by: Pan Xinhui <xinhui@linux.vnet.ibm.com> Reviewed-by: Nathan Fontenot <nf...@linux.vnet.ibm.com> &

Re: [PATCH v2] memory-hotplug: Fix kernel warning during memory hotplug on ppc64

at uses memory_probe_store to reserve memory, > this can interrupt the memory reservation process. This patch modifies > memory_probe_store to take the hotplug sysfs lock to prevent the online > of added memory before the completion of the probe. > > Signed-off-by: John Allen Revi

Re: [PATCH v2] memory-hotplug: Fix kernel warning during memory hotplug on ppc64

> On any architecture that uses memory_probe_store to reserve memory, > this can interrupt the memory reservation process. This patch modifies > memory_probe_store to take the hotplug sysfs lock to prevent the online > of added memory before the completion of the probe. > > Sig

Re: [RFC PATCH] driver: base: memory: Maintain correct mem->end_section_nr when memory block is partially filled

30] .do_one_initcall+0x110/0x270 > [c0013c583ce0] [c0c845d4] .kernel_init_freeable+0x278/0x360 > [c0013c583db0] [c000b5d4] .kernel_init+0x24/0x130 > [c0013c583e30] [c00094e8] .ret_from_kernel_thread+0x58/0x70 > > Fix this by updating the memory

Re: [RFC PATCH] driver: base: memory: Maintain correct mem-end_section_nr when memory block is partially filled

[c0013c583e30] [c00094e8] .ret_from_kernel_thread+0x58/0x70 Fix this by updating the memory block to always contain the right number of sections instead of assuming sections_per_block. Signed-off-by: Bharata B Rao bhar...@linux.vnet.ibm.com Cc: Nathan Fontenot nf...@linux.vnet.ibm.com

Re: [PATCH 06/31] arch/powerpc/pseries: use kmemdup rather than duplicating its implementation

On 08/07/2015 02:59 AM, Andrzej Hajda wrote: > The patch was generated using fixed coccinelle semantic patch > scripts/coccinelle/api/memdup.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320 > > Signed-off-by: Andrzej Hajda Reviewed-b

Re: [PATCH 05/31] arch/powerpc/nvram: use kmemdup rather than duplicating its implementation

On 08/07/2015 02:59 AM, Andrzej Hajda wrote: > The patch was generated using fixed coccinelle semantic patch > scripts/coccinelle/api/memdup.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320 > > Signed-off-by: Andrzej Hajda Reviewed-b

Re: [PATCH 05/31] arch/powerpc/nvram: use kmemdup rather than duplicating its implementation

On 08/07/2015 02:59 AM, Andrzej Hajda wrote: The patch was generated using fixed coccinelle semantic patch scripts/coccinelle/api/memdup.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320 Signed-off-by: Andrzej Hajda a.ha...@samsung.com Reviewed-by: Nathan Fontenot nf

Re: [PATCH 06/31] arch/powerpc/pseries: use kmemdup rather than duplicating its implementation

On 08/07/2015 02:59 AM, Andrzej Hajda wrote: The patch was generated using fixed coccinelle semantic patch scripts/coccinelle/api/memdup.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320 Signed-off-by: Andrzej Hajda a.ha...@samsung.com Reviewed-by: Nathan Fontenot nf

Re: powerpc,numa: Memory hotplug to memory-less nodes ?

On 06/23/2015 11:01 PM, Bharata B Rao wrote: > So will it be correct to say that memory hotplug to memory-less node > isn't supported by PowerPC kernel ? Should I enforce the same in QEMU > for PowerKVM ? > I'm not sure if that is correct. It appears that we initialize all online nodes, even

Re: powerpc,numa: Memory hotplug to memory-less nodes ?

On 06/23/2015 11:01 PM, Bharata B Rao wrote: So will it be correct to say that memory hotplug to memory-less node isn't supported by PowerPC kernel ? Should I enforce the same in QEMU for PowerKVM ? I'm not sure if that is correct. It appears that we initialize all online nodes, even those

Re: of/dynamic: Fix test for PPC_PSERIES

On 06/04/2015 05:57 AM, Michael Ellerman wrote: > On Thu, 2015-04-06 at 09:34:41 UTC, Geert Uytterhoeven wrote: >> "IS_ENABLED(PPC_PSERIES)" always evaluates to false, as IS_ENABLED() is >> supposed to be used with the full Kconfig symbol name, including the >> "CONFIG_" prefix. >> >> Add the

Re: of/dynamic: Fix test for PPC_PSERIES

On 06/04/2015 05:57 AM, Michael Ellerman wrote: On Thu, 2015-04-06 at 09:34:41 UTC, Geert Uytterhoeven wrote: IS_ENABLED(PPC_PSERIES) always evaluates to false, as IS_ENABLED() is supposed to be used with the full Kconfig symbol name, including the CONFIG_ prefix. Add the missing CONFIG_

Re: [PATCH v2 07/14] of/reconfig: Always use the same structure for notifiers

rt/bug on !update->dn / update->prop ? > > (Same for the rest of the patch) > > Or do you reckon it's pointless ? > I'm not sure it's worth it, if those are NULL pointers the drivers/of code would have tried to use them before invoking the notifier chain. We won't make it

Re: [PATCH v2 07/14] of/reconfig: Always use the same structure for notifiers

/of code would have tried to use them before invoking the notifier chain. We won't make it this far if they're NULL. Otherwise the patch looks good to me, Reviewed-by: Nathan Fontenot nf...@linux.vnet.ibm.com -Nathan -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [PATCH] powerpc: use device_online/offline() instead of cpu_up/down()

rom cpu_probe|release_store. > > This patch fixes errors on PowerVM systems that have cpu(s) added/removed > using dlpar operations; without this patch, the > /sys/devices/system/cpu/cpuN/online nodes do not correctly show the > online state of added/removed cpus. > > Signed-off-

Re: [PATCH] powerpc: use device_online/offline() instead of cpu_up/down()

fixes errors on PowerVM systems that have cpu(s) added/removed using dlpar operations; without this patch, the /sys/devices/system/cpu/cpuN/online nodes do not correctly show the online state of added/removed cpus. Signed-off-by: Dan Streetman ddstr...@ieee.org Cc: Nathan Fontenot nf

Re: [PATCH] MAINTAINERS: nx-842 driver maintainer change

On 10/17/2014 06:19 PM, Dan Streetman wrote: > Change maintainer of nx-842 compression coprocessor driver > to Dan Streetman. > > Signed-off-by: Dan Streetman > Cc: Nathan Fontenot Acked-by: Nathan Fontenot > --- > MAINTAINERS | 2 +- > 1 file changed, 1

Re: [PATCH] MAINTAINERS: nx-842 driver maintainer change

On 10/17/2014 06:19 PM, Dan Streetman wrote: Change maintainer of nx-842 compression coprocessor driver to Dan Streetman. Signed-off-by: Dan Streetman ddstr...@ieee.org Cc: Nathan Fontenot nf...@linux.vnet.ibm.com Acked-by: Nathan Fontenot nf...@linux.vnet.ibm.com --- MAINTAINERS | 2

Re: [PATCH] pseries: Make CPU hotplug path endian safe

On 09/05/2014 04:16 AM, bharata@gmail.com wrote: > From: Bharata B Rao > > - ibm,rtas-configure-connector should treat the RTAS data as big endian. > - Treat ibm,ppc-interrupt-server#s as big-endian when setting > smp_processor_id during hotplug. > > Signed-off-by: Bharata B Rao > --- >

Re: [PATCH] pseries: Make CPU hotplug path endian safe

On 09/05/2014 04:16 AM, bharata@gmail.com wrote: From: Bharata B Rao bhar...@linux.vnet.ibm.com - ibm,rtas-configure-connector should treat the RTAS data as big endian. - Treat ibm,ppc-interrupt-server#s as big-endian when setting smp_processor_id during hotplug. Signed-off-by:

Re: [PATCH 00/10] of: Core devicetree changeset support

On 07/23/2014 06:44 PM, Grant Likely wrote: > Hi all, > > This is a rollup of all the patches that I queued up today for > linux-next for the devicetree changeset and overlay work. I'm reposting > these patches because some have been significantly changed since their > first posting. None of the

Re: [PATCH 00/10] of: Core devicetree changeset support

On 07/23/2014 06:44 PM, Grant Likely wrote: Hi all, This is a rollup of all the patches that I queued up today for linux-next for the devicetree changeset and overlay work. I'm reposting these patches because some have been significantly changed since their first posting. None of the code

Re: [PATCH 1/1] drivers/crypto/nx/nx-842.c: use PAGE_ALIGNED instead of IS_ALIGNED(PAGE_SIZE

On 06/14/2014 05:09 PM, Fabian Frederick wrote: > use mm.h definition > > Cc: Nathan Fontenot > Cc: Marcelo Henrique Cerri > Signed-off-by: Fabian Frederick Acked-by: Nathan Fontenot > --- > drivers/crypto/nx/nx-842.c | 4 ++-- > 1 file changed, 2 insertions(+),

Re: [PATCH 1/1] drivers/crypto/nx/nx-842.c: use PAGE_ALIGNED instead of IS_ALIGNED(PAGE_SIZE

On 06/14/2014 05:09 PM, Fabian Frederick wrote: use mm.h definition Cc: Nathan Fontenot nf...@linux.vnet.ibm.com Cc: Marcelo Henrique Cerri mhce...@linux.vnet.ibm.com Signed-off-by: Fabian Frederick f...@skynet.be Acked-by: Nathan Fontenot nf...@linux.vnet.ibm.com --- drivers/crypto/nx

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/09/2014 11:17 PM, Li Zhong wrote: > On Wed, 2014-04-09 at 12:39 -0500, Nathan Fontenot wrote: >> On 04/08/2014 02:47 PM, Dave Hansen wrote: >>> >>> That document really needs to be updated to stop referring to sections >>> (at least in the descript

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/09/2014 11:17 PM, Li Zhong wrote: On Wed, 2014-04-09 at 12:39 -0500, Nathan Fontenot wrote: On 04/08/2014 02:47 PM, Dave Hansen wrote: That document really needs to be updated to stop referring to sections (at least in the descriptions of the user interface). We can not change

[PATCH] Update Maintainers for IBM Power 842, vscsi, and vfc drivers

Update the MAINTAINERS file to indicate the current maintainers for the IBM Power 842 Compression driver, IBM Power Virtual SCSI driver and the IBM Power Virtual FC Driver. Signed-off-by: Nathan Fontenot --- MAINTAINERS | 16 +++- 1 file changed, 11 insertions(+), 5 deletions

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/08/2014 02:47 PM, Dave Hansen wrote: > > That document really needs to be updated to stop referring to sections > (at least in the descriptions of the user interface). We can not change > the units of phys_index/end_phys_index without also changing > block_size_bytes. > Here is a first

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/08/2014 02:47 PM, Dave Hansen wrote: > On 04/08/2014 11:23 AM, Nathan Fontenot wrote: >> On 04/08/2014 11:13 AM, Dave Hansen wrote: >>> On 04/08/2014 01:27 AM, Li Zhong wrote: >>>> If Dave and others don't have further objections, it seems this small >&g

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/09/2014 10:49 AM, Dave Hansen wrote: > On 04/09/2014 02:20 AM, Li Zhong wrote: >> Or do you mean we don't need to expose any information related to >> SECTION to userspace? > > Right, we don't need to expose sections themselves to userspace. Do we? > No. the layout in sysfs is based in

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/09/2014 10:49 AM, Dave Hansen wrote: On 04/09/2014 02:20 AM, Li Zhong wrote: Or do you mean we don't need to expose any information related to SECTION to userspace? Right, we don't need to expose sections themselves to userspace. Do we? No. the layout in sysfs is based in

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/08/2014 02:47 PM, Dave Hansen wrote: On 04/08/2014 11:23 AM, Nathan Fontenot wrote: On 04/08/2014 11:13 AM, Dave Hansen wrote: On 04/08/2014 01:27 AM, Li Zhong wrote: If Dave and others don't have further objections, it seems this small userspace incompatibility could be accepted

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/08/2014 02:47 PM, Dave Hansen wrote: That document really needs to be updated to stop referring to sections (at least in the descriptions of the user interface). We can not change the units of phys_index/end_phys_index without also changing block_size_bytes. Here is a first pass at

[PATCH] Update Maintainers for IBM Power 842, vscsi, and vfc drivers

Update the MAINTAINERS file to indicate the current maintainers for the IBM Power 842 Compression driver, IBM Power Virtual SCSI driver and the IBM Power Virtual FC Driver. Signed-off-by: Nathan Fontenot nf...@linux.vnet.ibm.com --- MAINTAINERS | 16 +++- 1 file changed, 11

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/08/2014 11:13 AM, Dave Hansen wrote: > On 04/08/2014 01:27 AM, Li Zhong wrote: >> If Dave and others don't have further objections, it seems this small >> userspace incompatibility could be accepted by most of us, and I don't >> need to make a version 2. > > Let me ask another question

Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

On 04/08/2014 11:13 AM, Dave Hansen wrote: On 04/08/2014 01:27 AM, Li Zhong wrote: If Dave and others don't have further objections, it seems this small userspace incompatibility could be accepted by most of us, and I don't need to make a version 2. Let me ask another question then. What

Re: [PATCH v2] powerpc/le: enable RTAS events support

w patch is largely inspired by Nathan's work: we get rid of all > the bit fields in the RTAS event structures (even the unused ones, for > consistency). We also introduce endian safe accessors for the fields used > by the kernel (trivial rtas_error_type() accessor added for consistency

Re: [PATCH v2] powerpc/le: enable RTAS events support

inspired by Nathan's work: we get rid of all the bit fields in the RTAS event structures (even the unused ones, for consistency). We also introduce endian safe accessors for the fields used by the kernel (trivial rtas_error_type() accessor added for consistency). Cc: Nathan Fontenot nf

Re: [RFC PATCH] powerpc/le: enable RTAS events support

This is the patch that I worked up at the same time as Greg, the biggest difference being that I took the approach of doing and's, and shifting as opposed to re-defining the bit fields for LE. One other difference is that I left out defines for bits in the error log structures that we currently

Re: [RFC PATCH] powerpc/le: enable RTAS events support

This is the patch that I worked up at the same time as Greg, the biggest difference being that I took the approach of doing and's, and shifting as opposed to re-defining the bit fields for LE. One other difference is that I left out defines for bits in the error log structures that we currently

Re: [PATCH] powerpc/le: enable RTAS events support

Greg, There is one more place that needs fixing up, in mobility_rtas_call(), and handle_rtas_event() in arch/powerpc/platforms/pseries/mobility.c. This relates to rtas event handling for PRRN notifications, we need to convert the scope variable (PRRN notifications re-use the extended log length

Re: [PATCH] powerpc/le: enable RTAS events support

Greg, There is one more place that needs fixing up, in mobility_rtas_call(), and handle_rtas_event() in arch/powerpc/platforms/pseries/mobility.c. This relates to rtas event handling for PRRN notifications, we need to convert the scope variable (PRRN notifications re-use the extended log length

  1   2   >