* Re: [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Li Zhong @ 2012-05-18 12:17 UTC (permalink / raw)
To: Deepthi Dharwar
Cc: Paul E. McKenney, PowerPC email list, Paul Mackerras, LKML
In-Reply-To: <4FB63176.5040107@linux.vnet.ibm.com>
On Fri, 2012-05-18 at 16:54 +0530, Deepthi Dharwar wrote:
> On 05/18/2012 08:24 AM, Li Zhong wrote:
>
> > On Thu, 2012-05-17 at 15:52 +0530, Deepthi Dharwar wrote:
> >> On 05/17/2012 09:58 AM, Benjamin Herrenschmidt wrote:
> >>
> >>> On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
> >>>> This patch tries to fix following lockdep complaints:
> >>>
> >>> .../...
> >>>
> >>>> pseries_notify_cpu_idle_add_cpu() actually does
> >>>> cpuidle_disable_device(), and then cpuidle_enable_device(), which
> >>>> releases and allocates the resources respectively. ( Also, all the data
> >>>> are cleared and reinitialized after this cycle). The problem here is:
> >>>> something like kzalloc(GFP_KERNEL), wait_for_completion() would have
> >>>> problems running here where irqs are still disabled.
> >>
> >>
> >> This is true when the system is booting up.
> >>
> >>>
> >>> So yes, it looks definitely fishy. I don't have time to study cpuidle
> >>> today to check whether that's correct or not so I'm CCing Deepthi
> >>> Dharwar who did all that cpuidle work for pseries.
> >>>
> >>> Deepthi, can you check whether that patch is correct ?
> >>
> >>
> >> pseries_notify_cpu_idle_add_cpu() is essential to be called for
> >> hotplug event. So by removing this call completely wouldn't
> >> support cpus registering under cpuidle on hotplug and default idle is
> >> executed on those with do not give much powersavings.
> >
> > Maybe I missed that part.. would you please give some details how
> > removing this would prevent powersaving cpuidle being called after
> > hotplug?
> >
> > After rereading the codes, I think ppc_md.power_save() is the one you
> > mentioned that could give much powersavings?
> >
> > It is registered as pSeries_idle(), which calls cpuidle_idle_call().
> > It seems to me that it would still be called after hotplug.
> >
> > Or maybe I misunderstood your point?
>
>
> If cpuidle_idle_call() fails, in case device is not present, off ,
> not initialized and not ready to use, default idle is called.
> Coming out of a hotplug event, it is good to cleanly exit out
> and reallocate all the resources when needed, rather than using the
> stale one to make sure this call succeeds always.
>
> Default idle executed in pSeries_idle() :
> HMT_low();
> HMT_very_low();
> This would not have much powersavings.
>From my testing, cpuidle_idle_call didn't fail after hotplug, so it
didn't fall back to the default idling. I still don't see any big
problems if we don't reallocate the resources.
>
> CPUIDLE subsystem needs to be informed when a hot plug event occurs
> and not a good practice to mask this subsystem from this system wide
> event.
Ok, I agree that the CPUIDLE subsystem should be notified about the hot
plug events. Thank you.
I think this would be included in your coming patch, and I could just
stop here, hehe
>
> I agree that putting it in xics setup is not a good thing.
> Notifier would be a cleaner way of doing it.
> That way, duplication of resources allocated and released at boot
> time is not done.
>
>
> >
> >> Ideal way it to
> >> have a notifier in pseries backend driver for hotplug notification and
> >> then remove this function from here.
> >> I am currently working on this patch, will post it out soon.
> >>
> >>>
> >>>> Actually, cpuidle_enable_device() is called for each possible cpu when
> >>>> the driver is registered. So I don't think the resources needed to be
> >>>> released and allocated each time cpu becomes online. Something like
> >>>> cpuidle_reset_device() would be enough to clear and reinitialize the
> >>>> data.
> >>>>
> >>>> However, after some studying of the data to be cleared, I think it's
> >>>> also reasonable to keep the previous data. For example:
> >>>>
> >>>> /sys/devices/system/cpu/cpu#/cpuidle/state#/usage
> >>>> the number of times this idle state has been entered
> >>>> /sys/devices/system/cpu/cpu#/cpuidle/state#/time
> >>>> the amount of time spent in this idle state
> >>>>
> >>>> So I think we could just remove the function call doing the
> >>>> disable/enable cycle:
> >>>>
> >>>> Please correct me if I missed anything.
> >>
> >>
> >> If removed, this would not handle cpu hotplug events for cpuidle.
> >>
> >>
> >>>>
> >>>> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >>>> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> >>>> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >>>> ---
> >>>> arch/powerpc/platforms/pseries/smp.c | 1 -
> >>>> 1 files changed, 0 insertions(+), 1 deletions(-)
> >>>>
> >>>> diff --git a/arch/powerpc/platforms/pseries/smp.c
> >>>> b/arch/powerpc/platforms/pseries/smp.c
> >>>> index e16bb8d..71706bc 100644
> >>>> --- a/arch/powerpc/platforms/pseries/smp.c
> >>>> +++ b/arch/powerpc/platforms/pseries/smp.c
> >>>> @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
> >>>> set_cpu_current_state(cpu, CPU_STATE_ONLINE);
> >>>> set_default_offline_state(cpu);
> >>>> #endif
> >>>> - pseries_notify_cpuidle_add_cpu(cpu);
> >>>> }
> >>>>
> >>>> static int __devinit smp_pSeries_kick_cpu(int nr)
> >>>
> >>>
> >>>
> >>
> >> Cheers,
> >> Deepthi
> >
> >
> >
>
>
^ permalink raw reply
* Re: [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Deepthi Dharwar @ 2012-05-18 11:24 UTC (permalink / raw)
To: Li Zhong; +Cc: Paul E. McKenney, PowerPC email list, Paul Mackerras, LKML
In-Reply-To: <1337309699.2626.11.camel@ThinkPad-T420>
On 05/18/2012 08:24 AM, Li Zhong wrote:
> On Thu, 2012-05-17 at 15:52 +0530, Deepthi Dharwar wrote:
>> On 05/17/2012 09:58 AM, Benjamin Herrenschmidt wrote:
>>
>>> On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
>>>> This patch tries to fix following lockdep complaints:
>>>
>>> .../...
>>>
>>>> pseries_notify_cpu_idle_add_cpu() actually does
>>>> cpuidle_disable_device(), and then cpuidle_enable_device(), which
>>>> releases and allocates the resources respectively. ( Also, all the data
>>>> are cleared and reinitialized after this cycle). The problem here is:
>>>> something like kzalloc(GFP_KERNEL), wait_for_completion() would have
>>>> problems running here where irqs are still disabled.
>>
>>
>> This is true when the system is booting up.
>>
>>>
>>> So yes, it looks definitely fishy. I don't have time to study cpuidle
>>> today to check whether that's correct or not so I'm CCing Deepthi
>>> Dharwar who did all that cpuidle work for pseries.
>>>
>>> Deepthi, can you check whether that patch is correct ?
>>
>>
>> pseries_notify_cpu_idle_add_cpu() is essential to be called for
>> hotplug event. So by removing this call completely wouldn't
>> support cpus registering under cpuidle on hotplug and default idle is
>> executed on those with do not give much powersavings.
>
> Maybe I missed that part.. would you please give some details how
> removing this would prevent powersaving cpuidle being called after
> hotplug?
>
> After rereading the codes, I think ppc_md.power_save() is the one you
> mentioned that could give much powersavings?
>
> It is registered as pSeries_idle(), which calls cpuidle_idle_call().
> It seems to me that it would still be called after hotplug.
>
> Or maybe I misunderstood your point?
If cpuidle_idle_call() fails, in case device is not present, off ,
not initialized and not ready to use, default idle is called.
Coming out of a hotplug event, it is good to cleanly exit out
and reallocate all the resources when needed, rather than using the
stale one to make sure this call succeeds always.
Default idle executed in pSeries_idle() :
HMT_low();
HMT_very_low();
This would not have much powersavings.
CPUIDLE subsystem needs to be informed when a hot plug event occurs
and not a good practice to mask this subsystem from this system wide
event.
I agree that putting it in xics setup is not a good thing.
Notifier would be a cleaner way of doing it.
That way, duplication of resources allocated and released at boot
time is not done.
>
>> Ideal way it to
>> have a notifier in pseries backend driver for hotplug notification and
>> then remove this function from here.
>> I am currently working on this patch, will post it out soon.
>>
>>>
>>>> Actually, cpuidle_enable_device() is called for each possible cpu when
>>>> the driver is registered. So I don't think the resources needed to be
>>>> released and allocated each time cpu becomes online. Something like
>>>> cpuidle_reset_device() would be enough to clear and reinitialize the
>>>> data.
>>>>
>>>> However, after some studying of the data to be cleared, I think it's
>>>> also reasonable to keep the previous data. For example:
>>>>
>>>> /sys/devices/system/cpu/cpu#/cpuidle/state#/usage
>>>> the number of times this idle state has been entered
>>>> /sys/devices/system/cpu/cpu#/cpuidle/state#/time
>>>> the amount of time spent in this idle state
>>>>
>>>> So I think we could just remove the function call doing the
>>>> disable/enable cycle:
>>>>
>>>> Please correct me if I missed anything.
>>
>>
>> If removed, this would not handle cpu hotplug events for cpuidle.
>>
>>
>>>>
>>>> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>>>> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
>>>> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>>>> ---
>>>> arch/powerpc/platforms/pseries/smp.c | 1 -
>>>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/platforms/pseries/smp.c
>>>> b/arch/powerpc/platforms/pseries/smp.c
>>>> index e16bb8d..71706bc 100644
>>>> --- a/arch/powerpc/platforms/pseries/smp.c
>>>> +++ b/arch/powerpc/platforms/pseries/smp.c
>>>> @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
>>>> set_cpu_current_state(cpu, CPU_STATE_ONLINE);
>>>> set_default_offline_state(cpu);
>>>> #endif
>>>> - pseries_notify_cpuidle_add_cpu(cpu);
>>>> }
>>>>
>>>> static int __devinit smp_pSeries_kick_cpu(int nr)
>>>
>>>
>>>
>>
>> Cheers,
>> Deepthi
>
>
>
^ permalink raw reply
* Re: [PATCH] mtd: Fix typo in Kconfig
From: Artem Bityutskiy @ 2012-05-18 11:00 UTC (permalink / raw)
To: Frank Svendsboe; +Cc: dbaryshkov, linuxppc-dev, randy.dunlap, linux-mtd
In-Reply-To: <1337287389-28386-1-git-send-email-frank.svendsboe@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Thu, 2012-05-17 at 22:43 +0200, Frank Svendsboe wrote:
> MTD_OF_PARTS and the default setting is not working due to using 'Y'
> instead of 'y', introduced in commit
> d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and
> possibly other boards using DTS defined partitions and not having
> CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root
> after v3.1.
The commit was released in v3.2, so it not v3.1 probably?
> Signed-off-by: Frank Svendsboe <frank.svendsboe@gmail.com>
I've amended the subject to make it look scarier than just a fix of a
typo, added a tag for the stable tree, and pushed to l2-mtd.git, thanks!
commit aa2465b2d5d44defb269ac66a2d2b6e6b8feb399
Author: Frank Svendsboe <frank.svendsboe@gmail.com>
Date: Thu May 17 22:43:09 2012 +0200
mtd: of_parts: fix breakage in Kconfig
MTD_OF_PARTS and the default setting is not working due to using 'Y'
instead of 'y', introduced in commit
d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and
possibly other boards using DTS defined partitions and not having
CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root.
Signed-off-by: Frank Svendsboe <frank.svendsboe@gmail.com>
Cc: stable@kernel.org [3.2+]
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Re: Build regressions/improvements in v3.4-rc7
From: Michael Ellerman @ 2012-05-18 7:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, Geert Uytterhoeven, linux-kernel, Linuxppc-dev
In-Reply-To: <4FB546A4.7090502@freescale.com>
On Thu, 2012-05-17 at 13:42 -0500, Timur Tabi wrote:
> Benjamin Herrenschmidt wrote:
> > + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
> >> fsl_diu_monitor_port' declared inside parameter list [-Werror]: =>
> >> 70:9, 84:9, 88:36
> >> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
> >> a value, in function returning void [-Werror]: => 189:2
> >> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
> >> declaration isn't a prototype [-Werror=strict-prototypes]: => 69:5,
> >> 88:6, 83:6, 187:1
> >> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
> >> only this definition or declaration, which is probably not what you
> >> want [-Werror]: => 70:9
>
> So I think I have a fix for these, but I still would like the actual
> .config so that I can be sure.
I believe it's this one:
http://kisskb.ellerman.id.au/kisskb/buildresult/6312867/config/
cheers
^ permalink raw reply
* Re: [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Li Zhong @ 2012-05-18 2:54 UTC (permalink / raw)
To: Deepthi Dharwar
Cc: Paul E. McKenney, PowerPC email list, Paul Mackerras, LKML
In-Reply-To: <4FB4D14A.20903@linux.vnet.ibm.com>
On Thu, 2012-05-17 at 15:52 +0530, Deepthi Dharwar wrote:
> On 05/17/2012 09:58 AM, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
> >> This patch tries to fix following lockdep complaints:
> >
> > .../...
> >
> >> pseries_notify_cpu_idle_add_cpu() actually does
> >> cpuidle_disable_device(), and then cpuidle_enable_device(), which
> >> releases and allocates the resources respectively. ( Also, all the data
> >> are cleared and reinitialized after this cycle). The problem here is:
> >> something like kzalloc(GFP_KERNEL), wait_for_completion() would have
> >> problems running here where irqs are still disabled.
>
>
> This is true when the system is booting up.
>
> >
> > So yes, it looks definitely fishy. I don't have time to study cpuidle
> > today to check whether that's correct or not so I'm CCing Deepthi
> > Dharwar who did all that cpuidle work for pseries.
> >
> > Deepthi, can you check whether that patch is correct ?
>
>
> pseries_notify_cpu_idle_add_cpu() is essential to be called for
> hotplug event. So by removing this call completely wouldn't
> support cpus registering under cpuidle on hotplug and default idle is
> executed on those with do not give much powersavings.
Maybe I missed that part.. would you please give some details how
removing this would prevent powersaving cpuidle being called after
hotplug?
After rereading the codes, I think ppc_md.power_save() is the one you
mentioned that could give much powersavings?
It is registered as pSeries_idle(), which calls cpuidle_idle_call().
It seems to me that it would still be called after hotplug.
Or maybe I misunderstood your point?
> Ideal way it to
> have a notifier in pseries backend driver for hotplug notification and
> then remove this function from here.
> I am currently working on this patch, will post it out soon.
>
> >
> >> Actually, cpuidle_enable_device() is called for each possible cpu when
> >> the driver is registered. So I don't think the resources needed to be
> >> released and allocated each time cpu becomes online. Something like
> >> cpuidle_reset_device() would be enough to clear and reinitialize the
> >> data.
> >>
> >> However, after some studying of the data to be cleared, I think it's
> >> also reasonable to keep the previous data. For example:
> >>
> >> /sys/devices/system/cpu/cpu#/cpuidle/state#/usage
> >> the number of times this idle state has been entered
> >> /sys/devices/system/cpu/cpu#/cpuidle/state#/time
> >> the amount of time spent in this idle state
> >>
> >> So I think we could just remove the function call doing the
> >> disable/enable cycle:
> >>
> >> Please correct me if I missed anything.
>
>
> If removed, this would not handle cpu hotplug events for cpuidle.
>
>
> >>
> >> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> >> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >> ---
> >> arch/powerpc/platforms/pseries/smp.c | 1 -
> >> 1 files changed, 0 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/powerpc/platforms/pseries/smp.c
> >> b/arch/powerpc/platforms/pseries/smp.c
> >> index e16bb8d..71706bc 100644
> >> --- a/arch/powerpc/platforms/pseries/smp.c
> >> +++ b/arch/powerpc/platforms/pseries/smp.c
> >> @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
> >> set_cpu_current_state(cpu, CPU_STATE_ONLINE);
> >> set_default_offline_state(cpu);
> >> #endif
> >> - pseries_notify_cpuidle_add_cpu(cpu);
> >> }
> >>
> >> static int __devinit smp_pSeries_kick_cpu(int nr)
> >
> >
> >
>
> Cheers,
> Deepthi
^ permalink raw reply
* [PATCH] powerpc: fix irq distribution
From: Kim Phillips @ 2012-05-18 1:11 UTC (permalink / raw)
To: linuxppc-dev
setting CONFIG_IRQ_ALL_CPUS distributes IRQs to CPUs only when
the number of online CPUs equals NR_CPUS. See commit
280ff97494e0fef4124bee5c52e39b23a18dd283 "sparc64: fix and
optimize irq distribution" for more details.
Using the online mask fixes IRQ-to-CPU distribution on systems
that boot with less than NR_CPUS.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/kernel/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 2a599ce..c05fd53 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -891,7 +891,7 @@ int irq_choose_cpu(const struct cpumask *mask)
{
int cpuid;
- if (cpumask_equal(mask, cpu_all_mask)) {
+ if (cpumask_equal(mask, cpu_online_mask)) {
static int irq_rover;
static DEFINE_RAW_SPINLOCK(irq_rover_lock);
unsigned long flags;
--
1.7.10.2
^ permalink raw reply related
* [PATCH] mtd: Fix typo in Kconfig
From: Frank Svendsboe @ 2012-05-17 20:43 UTC (permalink / raw)
To: linux-mtd
Cc: dbaryshkov, randy.dunlap, linuxppc-dev, Frank Svendsboe,
dedekind1
MTD_OF_PARTS and the default setting is not working due to using 'Y'
instead of 'y', introduced in commit
d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and
possibly other boards using DTS defined partitions and not having
CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root
after v3.1.
Signed-off-by: Frank Svendsboe <frank.svendsboe@gmail.com>
---
drivers/mtd/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 5760c1a..27143e0 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -128,7 +128,7 @@ config MTD_AFS_PARTS
config MTD_OF_PARTS
tristate "OpenFirmware partitioning information support"
- default Y
+ default y
depends on OF
help
This provides a partition parsing function which derives
--
1.7.5.4
^ permalink raw reply related
* Re: Build regressions/improvements in v3.4-rc7
From: Timur Tabi @ 2012-05-17 18:51 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <4FB547F9.7000804@freescale.com>
Scott Wood wrote:
> Regardless of the config that shows this, the MSR[GS] check should go
> away. If you have a /hypervisor node, you already know you're a guest.
Fair enough.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Scott Wood @ 2012-05-17 18:48 UTC (permalink / raw)
To: Timur Tabi
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <4FB546FB.807@freescale.com>
On 05/17/2012 01:44 PM, Timur Tabi wrote:
> Geert Uytterhoeven wrote:
>> powerpc randconfig
>
> Doesn't this generate a different .config every time it's run? Do I keep
> generating random .config files until the problem shows up?
>
Regardless of the config that shows this, the MSR[GS] check should go
away. If you have a /hypervisor node, you already know you're a guest.
-Scott
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Timur Tabi @ 2012-05-17 18:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev
In-Reply-To: <CAMuHMdVszy2sk6f045krqr=PPQFnd-GrtJYJMQCCPzkq-65psg@mail.gmail.com>
Geert Uytterhoeven wrote:
> powerpc randconfig
Doesn't this generate a different .config every time it's run? Do I keep
generating random .config files until the problem shows up?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Re: Build regressions/improvements in v3.4-rc7
From: Timur Tabi @ 2012-05-17 18:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, Linuxppc-dev,
Geert Uytterhoeven, Scott Wood
In-Reply-To: <1337212281.30558.17.camel@pasglop>
Benjamin Herrenschmidt wrote:
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
>> fsl_diu_monitor_port' declared inside parameter list [-Werror]: =>
>> 70:9, 84:9, 88:36
>> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
>> a value, in function returning void [-Werror]: => 189:2
>> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
>> declaration isn't a prototype [-Werror=strict-prototypes]: => 69:5,
>> 88:6, 83:6, 187:1
>> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
>> only this definition or declaration, which is probably not what you
>> want [-Werror]: => 70:9
So I think I have a fix for these, but I still would like the actual
.config so that I can be sure.
>> + drivers/virt/fsl_hypervisor.c: error: 'MSR_GS' undeclared (first
>> use in this function): => 799:80
I can't reproduce this one. MSR_GS is defined in reg_booke.h.
fsl_hypervisor.c should not be compiled on a non-booke platform. I don't
know if the fix is to add this to fsl_hypervisor.c:
#include <asm/reg_booke.h>
or if I should update the Kconfig:
config FSL_HV_MANAGER
tristate "Freescale hypervisor management driver"
depends on FSL_SOC
to
depends on FSL_BOOKE
or maybe
depends on FSL_BOOKE && FSL_SOC
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Re: Build regressions/improvements in v3.4-rc7
From: Geert Uytterhoeven @ 2012-05-17 18:42 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev
In-Reply-To: <CAOZdJXW2jmFG8hkBRMAsO-CJ3ruMd28LqS0b-BGZTU7FnpRi3Q@mail.gmail.com>
On Thu, May 17, 2012 at 7:52 PM, Tabi Timur-B04825 <B04825@freescale.com> w=
rote:
> On Thu, May 17, 2012 at 12:30 PM, Timur Tabi <timur@freescale.com> wrote:
>
>> Anyway, I think I see what the problem is, but it does appear when I use
>> the normal defconfigs. =C2=A0What .config was being used?
>
> I meant to say that it does NOT appear.
powerpc randconfig.
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: Re: Build regressions/improvements in v3.4-rc7
From: Tabi Timur-B04825 @ 2012-05-17 17:52 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Wood Scott-B07421, Parisc List, the arch/x86 maintainers,
linux-kernel@vger.kernel.org, Linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <4FB535D3.7000106@freescale.com>
On Thu, May 17, 2012 at 12:30 PM, Timur Tabi <timur@freescale.com> wrote:
> Anyway, I think I see what the problem is, but it does appear when I use
> the normal defconfigs. =A0What .config was being used?
I meant to say that it does NOT appear.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: Re: Build regressions/improvements in v3.4-rc7
From: Timur Tabi @ 2012-05-17 17:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, Linuxppc-dev,
Geert Uytterhoeven, Scott Wood
In-Reply-To: <1337212281.30558.17.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Thanks. These are all freescale platforms, the relevant people should be
> already but I've added Scott and Kumar to the CC list just in case.
Seeing how this is my code, I'd say the relevant people were not CC'd. :-)
Anyway, I think I see what the problem is, but it does appear when I use
the normal defconfigs. What .config was being used?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Anthony Foiani @ 2012-05-17 17:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Robert P. J. Day, Jeff Garzik, ashish kalra, Adrian Bunk
Greetings.
I was occasionally running into problems at boot time on an
MPC8315-based board (derived from the MPC831xRDB, apparently), using
SATA to talk to an SSD. My vendor suggested that I enable
CONFIG_MPC8315_DS.
That symbol is only found once in the entire kernel codebase:
$ git checkout v3.4-rc7
HEAD is now at 36be505... Linux 3.4-rc7
$ git grep -nH CONFIG_MPC8315_DS
drivers/ata/sata_fsl.c:729:#ifdef CONFIG_MPC8315_DS
There is no kconfig support for it at all.
It was added in 2007; further, this is the only commit in the entire
git history that contains this string:
commit e7eac96e8f0e57a6e9f94943557bc2b23be31471
Author: ashish kalra <ashish.kalra@freescale.com>
Date: Wed Oct 31 19:28:02 2007 +0800
ata/sata_fsl: Move MPC8315DS link speed limit workaround to specific ifdef
Signed-off-by: ashish kalra <ashish.kalra@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 5892472..e076e1f 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -652,6 +652,7 @@ static int sata_fsl_port_start(struct ata_port *ap)
VPRINTK("HControl = 0x%x\n", ioread32(hcr_base + HCONTROL));
VPRINTK("CHBA = 0x%x\n", ioread32(hcr_base + CHBA));
+#ifdef CONFIG_MPC8315_DS
/*
* Workaround for 8315DS board 3gbps link-up issue,
* currently limit SATA port to GEN1 speed
@@ -664,6 +665,7 @@ static int sata_fsl_port_start(struct ata_port *ap)
sata_fsl_scr_read(ap, SCR_CONTROL, &temp);
dev_printk(KERN_WARNING, dev, "scr_control, speed limited to %x\n",
temp);
+#endif
return 0;
}
This otherwise-unsupported variable was noted by Robert Day in 2008;
Adrian Bunk suggested a patch, but the Freescale folks said that it
was for a not-yet-mainlined board, so the patch was dropped:
http://marc.info/?l=linux-ide&m=121783965216004&w=2
As Robert notied again in 2010, it still wasn't mainlined:
http://marc.info/?l=linux-ide&m=121783965216004&w=2
And, obviously, it still isn't today.
Can the Freescale people tell us exactly what we should be testing to
determine when to enforce this restriction? A config variable that
points to a non-existent board doesn't seem much help.
Thanks,
Tony
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Frank Svendsbøe @ 2012-05-17 14:37 UTC (permalink / raw)
To: robert.karl.berger, Tony Breeds; +Cc: Wolfgang Denk, linuxppc-dev
In-Reply-To: <4FA68C98.5070209@gmail.com>
On Sun, May 6, 2012 at 4:37 PM, Robert Berger
<robert.karl.berger@gmail.com> wrote:
> On 04/02/2012 09:28 AM, Tony Breeds wrote:
>> On Mon, Apr 02, 2012 at 12:01:55PM +1000, Benjamin Herrenschmidt wrote:
>>
>>> Ok, I've asked Tony to have a look at splitting the build decision
>>> in arch/powerpc/boot along the same lines as the CPU families... ie onl=
y
>>> wrappers for platforms potentially supported by the built kernel. That
>>> should fix it.
>>
>> Please try this patch. =A0Only lightly tested here. =A0I haven't "split =
up"
>> src-wlib yet as I wanted to verify I'm on the right track.
>
> I can confirm that it fixes the kilauea problem. Builds and runs so far.
> Are you going to push this upstream?
>
I can confirm this too (applied to 3.4-rc7). Tony?
Best regards,
Frank
^ permalink raw reply
* Re: [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Deepthi Dharwar @ 2012-05-17 10:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: PowerPC email list, Paul E. McKenney, Paul Mackerras, LKML,
Li Zhong
In-Reply-To: <1337228910.30558.46.camel@pasglop>
On 05/17/2012 09:58 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
>> This patch tries to fix following lockdep complaints:
>
> .../...
>
>> pseries_notify_cpu_idle_add_cpu() actually does
>> cpuidle_disable_device(), and then cpuidle_enable_device(), which
>> releases and allocates the resources respectively. ( Also, all the data
>> are cleared and reinitialized after this cycle). The problem here is:
>> something like kzalloc(GFP_KERNEL), wait_for_completion() would have
>> problems running here where irqs are still disabled.
This is true when the system is booting up.
>
> So yes, it looks definitely fishy. I don't have time to study cpuidle
> today to check whether that's correct or not so I'm CCing Deepthi
> Dharwar who did all that cpuidle work for pseries.
>
> Deepthi, can you check whether that patch is correct ?
pseries_notify_cpu_idle_add_cpu() is essential to be called for
hotplug event. So by removing this call completely wouldn't
support cpus registering under cpuidle on hotplug and default idle is
executed on those with do not give much powersavings. Ideal way it to
have a notifier in pseries backend driver for hotplug notification and
then remove this function from here.
I am currently working on this patch, will post it out soon.
>
>> Actually, cpuidle_enable_device() is called for each possible cpu when
>> the driver is registered. So I don't think the resources needed to be
>> released and allocated each time cpu becomes online. Something like
>> cpuidle_reset_device() would be enough to clear and reinitialize the
>> data.
>>
>> However, after some studying of the data to be cleared, I think it's
>> also reasonable to keep the previous data. For example:
>>
>> /sys/devices/system/cpu/cpu#/cpuidle/state#/usage
>> the number of times this idle state has been entered
>> /sys/devices/system/cpu/cpu#/cpuidle/state#/time
>> the amount of time spent in this idle state
>>
>> So I think we could just remove the function call doing the
>> disable/enable cycle:
>>
>> Please correct me if I missed anything.
If removed, this would not handle cpu hotplug events for cpuidle.
>>
>> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
>> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/pseries/smp.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/smp.c
>> b/arch/powerpc/platforms/pseries/smp.c
>> index e16bb8d..71706bc 100644
>> --- a/arch/powerpc/platforms/pseries/smp.c
>> +++ b/arch/powerpc/platforms/pseries/smp.c
>> @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
>> set_cpu_current_state(cpu, CPU_STATE_ONLINE);
>> set_default_offline_state(cpu);
>> #endif
>> - pseries_notify_cpuidle_add_cpu(cpu);
>> }
>>
>> static int __devinit smp_pSeries_kick_cpu(int nr)
>
>
>
Cheers,
Deepthi
^ permalink raw reply
* Re: Fixing a cputhread code documentation
From: Anshuman Khandual @ 2012-05-17 5:30 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <4FB12570.9090503@linux.vnet.ibm.com>
Hey Ben,
Because its too minor a documentation fix, did not write any description.
Not sure how it works, I thought this would be clubbed with other incoming
documentation fix in the same area.
On Monday 14 May 2012 09:02 PM, Anshuman Khandual wrote:
> diff --git a/arch/powerpc/include/asm/cputhreads.h b/arch/powerpc/include/asm/cputhreads.h
> index ce516e5..ac3eedb 100644
> --- a/arch/powerpc/include/asm/cputhreads.h
> +++ b/arch/powerpc/include/asm/cputhreads.h
> @@ -9,7 +9,7 @@
> * Note: This implementation is limited to a power of 2 number of
> * threads per core and the same number for each core in the system
> * (though it would work if some processors had less threads as long
> - * as the CPU numbers are still allocated, just not brought offline).
> + * as the CPU numbers are still allocated, just not brought online).
> *
> * However, the API allows for a different implementation in the future
> * if needed, as long as you only use the functions and not the variables
>
> --
> Anshuman Khandual
^ permalink raw reply
* Re: [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Benjamin Herrenschmidt @ 2012-05-17 4:28 UTC (permalink / raw)
To: Li Zhong
Cc: PowerPC email list, Paul E. McKenney, Paul Mackerras, LKML,
deepthi
In-Reply-To: <1337227263.24471.23.camel@ThinkPad-T420>
On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
> This patch tries to fix following lockdep complaints:
.../...
> pseries_notify_cpu_idle_add_cpu() actually does
> cpuidle_disable_device(), and then cpuidle_enable_device(), which
> releases and allocates the resources respectively. ( Also, all the data
> are cleared and reinitialized after this cycle). The problem here is:
> something like kzalloc(GFP_KERNEL), wait_for_completion() would have
> problems running here where irqs are still disabled.
So yes, it looks definitely fishy. I don't have time to study cpuidle
today to check whether that's correct or not so I'm CCing Deepthi
Dharwar who did all that cpuidle work for pseries.
Deepthi, can you check whether that patch is correct ?
> Actually, cpuidle_enable_device() is called for each possible cpu when
> the driver is registered. So I don't think the resources needed to be
> released and allocated each time cpu becomes online. Something like
> cpuidle_reset_device() would be enough to clear and reinitialize the
> data.
>
> However, after some studying of the data to be cleared, I think it's
> also reasonable to keep the previous data. For example:
>
> /sys/devices/system/cpu/cpu#/cpuidle/state#/usage
> the number of times this idle state has been entered
> /sys/devices/system/cpu/cpu#/cpuidle/state#/time
> the amount of time spent in this idle state
>
> So I think we could just remove the function call doing the
> disable/enable cycle:
>
> Please correct me if I missed anything.
>
> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/smp.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/smp.c
> b/arch/powerpc/platforms/pseries/smp.c
> index e16bb8d..71706bc 100644
> --- a/arch/powerpc/platforms/pseries/smp.c
> +++ b/arch/powerpc/platforms/pseries/smp.c
> @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
> set_cpu_current_state(cpu, CPU_STATE_ONLINE);
> set_default_offline_state(cpu);
> #endif
> - pseries_notify_cpuidle_add_cpu(cpu);
> }
>
> static int __devinit smp_pSeries_kick_cpu(int nr)
^ permalink raw reply
* [PATCH powerpc] fix a lockdep complaint in start_secondary
From: Li Zhong @ 2012-05-17 4:01 UTC (permalink / raw)
To: LKML; +Cc: Paul E. McKenney, Paul Mackerras, PowerPC email list
This patch tries to fix following lockdep complaints:
[ 81.882506] =================================
[ 81.882508] [ INFO: inconsistent lock state ]
[ 81.882511] 3.4.0-rc4-autokern1 #1 Not tainted
[ 81.882513] ---------------------------------
[ 81.882516] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 81.882519] swapper/5/0 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 81.882522] (call_function.lock){?.....}, at:
[<c0000000000fdaa0>] .ipi_call_lock+0x20/0x40
[ 81.882536] {IN-HARDIRQ-W} state was registered at:
[ 81.882538] [<c0000000000f5a9c>] .__lock_acquire+0x44c/0x9e0
[ 81.882543] [<c0000000000f60f4>] .lock_acquire+0xc4/0x260
[ 81.882548] [<c00000000063f648>] ._raw_spin_lock+0x48/0x70
[ 81.882554]
[<c0000000000fede4>] .generic_smp_call_function_interrupt+0x1d4/0x320
[ 81.882559] [<c000000000037020>] .smp_ipi_demux+0x90/0x100
[ 81.882565] [<c00000000004f98c>] .icp_hv_ipi_action+0x5c/0xc0
[ 81.882571] [<c00000000013420c>] .handle_irq_event_percpu
+0xec/0x570
[ 81.882577] [<c000000000138ab4>] .handle_percpu_irq+0x84/0xd0
[ 81.882582] [<c0000000000221b4>] .call_handle_irq+0x1c/0x2c
[ 81.882588] [<c0000000000103fc>] .do_IRQ+0x16c/0x500
[ 81.882593] [<c0000000000038d0>] hardware_interrupt_common
+0x150/0x180
[ 81.882598] [<c000000000010a38>] .arch_local_irq_restore+0x38/0x90
[ 81.882603] [<c000000000017450>] .cpu_idle+0x250/0x2d0
[ 81.882607] [<c000000000651ce0>] .start_secondary+0x378/0x384
[ 81.882613] [<c00000000000936c>] .start_secondary_prolog+0x10/0x14
[ 81.882618] irq event stamp: 332475
[ 81.882620] hardirqs last enabled at (332475):
[<c000000000640414>] ._raw_spin_unlock_irqrestore+0x94/0xc0
[ 81.882625] hardirqs last disabled at (332474):
[<c00000000063f7c0>] ._raw_spin_lock_irqsave+0x30/0x90
[ 81.882631] softirqs last enabled at (332288):
[<c0000000000873c4>] .irq_enter+0x94/0xd0
[ 81.882636] softirqs last disabled at (332287):
[<c0000000000873b4>] .irq_enter+0x84/0xd0
[ 81.882640]
[ 81.882641] other info that might help us debug this:
[ 81.882644] Possible unsafe locking scenario:
[ 81.882645]
[ 81.882647] CPU0
[ 81.882649] ----
[ 81.882650] lock(call_function.lock);
[ 81.882654] <Interrupt>
[ 81.882656] lock(call_function.lock);
[ 81.882660]
[ 81.882661] *** DEADLOCK ***
[ 81.882662]
[ 81.882664] no locks held by swapper/5/0.
[ 81.882666]
[ 81.882667] stack backtrace:
[ 81.882669] Call Trace:
[ 81.882672] [c0000003c07bf860] [c0000000000146f4] .show_stack
+0x74/0x1c0 (unreliable)
[ 81.882678] [c0000003c07bf910] [c0000000000f1304] .print_usage_bug
+0x1e4/0x230
[ 81.882683] [c0000003c07bf9d0] [c0000000000f150c] .mark_lock_irq
+0x1bc/0x3c0
[ 81.882688] [c0000003c07bfa90] [c0000000000f18a0] .mark_lock
+0x190/0x4b0
[ 81.882693] [c0000003c07bfb40] [c0000000000f1d10] .mark_irqflags
+0x150/0x240
[ 81.882697] [c0000003c07bfbd0] [c0000000000f5a9c] .__lock_acquire
+0x44c/0x9e0
[ 81.882702] [c0000003c07bfce0] [c0000000000f60f4] .lock_acquire
+0xc4/0x260
[ 81.882707] [c0000003c07bfdc0] [c00000000063f648] ._raw_spin_lock
+0x48/0x70
[ 81.882712] [c0000003c07bfe50] [c0000000000fdaa0] .ipi_call_lock
+0x20/0x40
[ 81.882717] [c0000003c07bfed0] [c000000000651aa0] .start_secondary
+0x138/0x384
[ 81.882722] [c0000003c07bff90]
[c00000000000936c] .start_secondary_prolog+0x10/0x14
>From the log, ipi_call_lock() is called in start_secondary() with irqs
enabled. The irqs are enabled by smp_ops->setup_cpu(), in following call
chain:
start_secondary --> smp_ops->setup_cpu --> smp_xics_setup_cpu -->
pseries_notify_cpu_idle_add_cpu --> cpuidle_disable_device -->
cpuidle_remove_state_sysfs --> cpuidle_free_state_kobj -->
wait_for_completion --> wait_for_common
>From my understanding of the codes, I think it's not necessary to call
pseries_notify_cpu_idle_add_cpu() in the early start_secondary()
function before irqs could be enabled.
pseries_notify_cpu_idle_add_cpu() actually does
cpuidle_disable_device(), and then cpuidle_enable_device(), which
releases and allocates the resources respectively. ( Also, all the data
are cleared and reinitialized after this cycle). The problem here is:
something like kzalloc(GFP_KERNEL), wait_for_completion() would have
problems running here where irqs are still disabled.
Actually, cpuidle_enable_device() is called for each possible cpu when
the driver is registered. So I don't think the resources needed to be
released and allocated each time cpu becomes online. Something like
cpuidle_reset_device() would be enough to clear and reinitialize the
data.
However, after some studying of the data to be cleared, I think it's
also reasonable to keep the previous data. For example:
/sys/devices/system/cpu/cpu#/cpuidle/state#/usage
the number of times this idle state has been entered
/sys/devices/system/cpu/cpu#/cpuidle/state#/time
the amount of time spent in this idle state
So I think we could just remove the function call doing the
disable/enable cycle:
Please correct me if I missed anything.
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/smp.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index e16bb8d..71706bc 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
set_cpu_current_state(cpu, CPU_STATE_ONLINE);
set_default_offline_state(cpu);
#endif
- pseries_notify_cpuidle_add_cpu(cpu);
}
static int __devinit smp_pSeries_kick_cpu(int nr)
--
1.7.5.4
^ permalink raw reply related
* Re: linux-next: manual merge of the crypto tree with the powerpc tree
From: Herbert Xu @ 2012-05-17 3:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, linux-next, Paul Mackerras, Andreas Westin,
Kent Yoder, linuxppc-dev
In-Reply-To: <20120517132116.8a5378bce254fc39d20cb08a@canb.auug.org.au>
On Thu, May 17, 2012 at 01:21:16PM +1000, Stephen Rothwell wrote:
> Hi Herbert,
>
> Today's linux-next merge of the crypto tree got a conflict in
> drivers/crypto/Kconfig between commit aef7b31c8833 ("powerpc/crypto:
> Build files for the nx device driver") from the powerpc tree and commit
> 2789c08fffea ("crypto: ux500 - Add driver for CRYP hardware") from the
> crypto tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Looks fine. Thanks Stephen!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* linux-next: manual merge of the crypto tree with the powerpc tree
From: Stephen Rothwell @ 2012-05-17 3:21 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-kernel, linux-next, Paul Mackerras, Andreas Westin,
Kent Yoder, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]
Hi Herbert,
Today's linux-next merge of the crypto tree got a conflict in
drivers/crypto/Kconfig between commit aef7b31c8833 ("powerpc/crypto:
Build files for the nx device driver") from the powerpc tree and commit
2789c08fffea ("crypto: ux500 - Add driver for CRYP hardware") from the
crypto tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/crypto/Kconfig
index f1ceeef,69fdf18..0000000
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@@ -296,21 -295,15 +296,32 @@@ config CRYPTO_DEV_TEGRA_AE
To compile this driver as a module, choose M here: the module
will be called tegra-aes.
+config CRYPTO_DEV_NX
+ tristate "Support for Power7+ in-Nest cryptographic accleration"
+ depends on PPC64 && IBMVIO
+ select CRYPTO_AES
+ select CRYPTO_CBC
+ select CRYPTO_ECB
+ select CRYPTO_CCM
+ select CRYPTO_GCM
+ select CRYPTO_AUTHENC
+ select CRYPTO_XCBC
+ select CRYPTO_SHA256
+ select CRYPTO_SHA512
+ help
+ Support for Power7+ in-Nest cryptographic acceleration. This
+ module supports acceleration for AES and SHA2 algorithms. If you
+ choose 'M' here, this module will be called nx_crypto.
+
+ config CRYPTO_DEV_UX500
+ tristate "Driver for ST-Ericsson UX500 crypto hardware acceleration"
+ depends on ARCH_U8500
+ select CRYPTO_ALGAPI
+ help
+ Driver for ST-Ericsson UX500 crypto engine.
+
+ if CRYPTO_DEV_UX500
+ source "drivers/crypto/ux500/Kconfig"
+ endif # if CRYPTO_DEV_UX500
+
endif # CRYPTO_HW
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: John David Anglin @ 2012-05-17 0:27 UTC (permalink / raw)
To: James Bottomley
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, James Morris,
Linuxppc-dev, Dmitry Kasatkin, Geert Uytterhoeven
In-Reply-To: <1337179563.2985.80.camel@dabdike.int.hansenpartnership.com>
On 16-May-12, at 10:46 AM, James Bottomley wrote:
> Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm
> code.
> The error in this case appears to be that umul_ppm() is implemented as
> an xmpyu instruction. That's a floating point instruction. We
> deliberately compile the kernel with floating point disabled because
> we
> don't want to save and restore the floating point register file on
> each
> context switch, hence the operand constraints are unsatisfiable.
I haven't tried this but I think the parisc implementation of umul_ppmm
can be deleted. There is a generic version in the file.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Benjamin Herrenschmidt @ 2012-05-16 23:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, Linuxppc-dev,
Scott Wood
In-Reply-To: <CAMuHMdUtL4_mv-e-EQAZmNcb9dAT=PXB59i7Vuj2vf8NnaBFzQ@mail.gmail.com>
On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > JFYI, when comparing v3.4-rc7 to v3.4-rc6[3], the summaries are:
> > - build errors: +15/-14
>
> 15 regressions:
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
> fsl_diu_monitor_port' declared inside parameter list [-Werror]: =>
> 70:9, 84:9, 88:36
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
> a value, in function returning void [-Werror]: => 189:2
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
> declaration isn't a prototype [-Werror=strict-prototypes]: => 69:5,
> 88:6, 83:6, 187:1
> + arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
> only this definition or declaration, which is probably not what you
> want [-Werror]: => 70:9
> + drivers/virt/fsl_hypervisor.c: error: 'MSR_GS' undeclared (first
> use in this function): => 799:80
>
> powerpc randconfig
Thanks. These are all freescale platforms, the relevant people should be
already but I've added Scott and Kumar to the CC list just in case.
Cheers,
Ben.
^ permalink raw reply
* Re: Build regressions/improvements in v3.4-rc7
From: Kasatkin, Dmitry @ 2012-05-16 15:59 UTC (permalink / raw)
To: James Bottomley
Cc: Parisc List, the arch/x86 maintainers, linux-kernel, James Morris,
Linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <1337179563.2985.80.camel@dabdike.int.hansenpartnership.com>
On Wed, May 16, 2012 at 5:46 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
>> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> =C2=A0 + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 50:70
>> =C2=A0 + lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/generic_mpih-mul3.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/mpih-div.c: error: inconsistent operand constraints in =
an
>> 'asm': =C2=A0=3D> 135:122, 135:371, 97:122, 106:121, 106:370, 97:371
>>
>> parisc-allmodconfig
>
> Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm code.
> The error in this case appears to be that umul_ppm() is implemented as
> an xmpyu instruction. =C2=A0That's a floating point instruction. =C2=A0We
> deliberately compile the kernel with floating point disabled because we
> don't want to save and restore the floating point register file on each
> context switch, hence the operand constraints are unsatisfiable.
>
> It appears to be completely untested on non-x86 and to have been
> imported via the security tree ... what are we supposed to do with this?
> I thought the general principle was that asm code was really supposed to
> be confined to the arch directories?
>
> James
>
>
Yes.. it is suxx.
But it is only longlong.h and inherited from gpg..
And now there is a stuff such as /include/math-emu/soft-fp and
<stdlib/longlong.h>
I planned to look to that but now I will start doing it right away.
- Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox