* Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
From: Kumar Gala @ 2008-07-16 22:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel, davej
In-Reply-To: <20080716214722.GA6251@ld0162-tx32.am.freescale.net>
On Jul 16, 2008, at 4:47 PM, Scott Wood wrote:
> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
>> If we don't enable FS_ENET we get build issues:
>>
>> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
>> arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
>> `alloc_mdio_bitbang'
>> arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to
>> `mdiobus_register'
>
> How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG.
>
>> +#ifdef CONFIG_FS_ENET_MDIO_FCC
>> static void ep8248e_set_mdc(struct mdiobb_ctrl *ctrl, int level)
>> {
>> if (level)
>> @@ -164,6 +165,7 @@ static struct of_platform_driver
>> ep8248e_mdio_driver = {
>> .probe = ep8248e_mdio_probe,
>> .remove = ep8248e_mdio_remove,
>> };
>> +#endif
>
> This is wrong -- ep8248e doesn't use the FS_ENET_MDIO_FCC code.
You're correct this should be CONFIG_MDIO_BITBANG
- k
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
From: Dave Jones @ 2008-07-16 21:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <20080716214722.GA6251@ld0162-tx32.am.freescale.net>
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
> > If we don't enable FS_ENET we get build issues:
> >
> > arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> > arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
> > arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
>
> How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG.
If CONFIG_PHYLIB=m however, that doesn't make any difference, because
vmlinuz is trying to use a symbol which now lives in a module.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
From: Kumar Gala @ 2008-07-16 22:10 UTC (permalink / raw)
To: Dave Jones; +Cc: Scott Wood, linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <20080716215745.GA17093@redhat.com>
On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
> On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
>> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
>>> If we don't enable FS_ENET we get build issues:
>>>
>>> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
>>> arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
>>> `alloc_mdio_bitbang'
>>> arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to
>>> `mdiobus_register'
>>
>> How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG.
>
> If CONFIG_PHYLIB=m however, that doesn't make any difference, because
> vmlinuz is trying to use a symbol which now lives in a module.
The mdiobus_register make sense, I'm not sure get why
alloc_mdio_bitbang is undefined.
- k
^ permalink raw reply
* [PATCH] powerpc: fix support for latencytop
From: Arnd Bergmann @ 2008-07-16 22:12 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080716202236.GZ9594@localdomain>
We need to pass the kernel stack pointer instead of the user space
stack pointer in save_stack_trace_tsk().
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
On Wednesday 16 July 2008, Nathan Lynch wrote:
> Arnd Bergmann wrote:
> > Implement save_stack_trace_tsk on powerpc, so that we can run with
> > latencytop.
>
> So I tried latencytop with linux-next and got the following oops, but
> I didn't really look into it yet.
Oh, I didn't even realize that benh had merged that patch of mine.
As I wrote in the description, it was entirely untested. You found
another obvious bug: The code was passing the user space stack
pointer instead of the kernel stack pointer.
Again, this patch is entirely untested, and I would not be at all
surprised to find other trivial bugs.
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -59,6 +59,6 @@ EXPORT_SYMBOL_GPL(save_stack_trace);
void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
{
- save_context_stack(trace, tsk->thread.regs->gpr[1], tsk, 0);
+ save_context_stack(trace, tsk->thread.ksp, tsk, 0);
}
EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
^ permalink raw reply
* Re: [PATCH] Fix wrong 'no interrupt' handling in of_i2c
From: Sean MacLennan @ 2008-07-16 22:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Wolfram Sang
In-Reply-To: <fa686aa40806281216v71f33a70n67eca1c1e69417d8@mail.gmail.com>
On Sat, 28 Jun 2008 13:16:16 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On Sat, Jun 28, 2008 at 12:31 PM, Wolfram Sang
> <w.sang@pengutronix.de> wrote:
> > If an I2C device node does not specify an interrupt, the .irq
> > member of the board_info struct was set to -1. This caused crashes
> > on following irq_dispose_mappings. Leave it NO_IRQ as returned from
> > irq_of_parse_and_map. (Suggesting -1 as 'i2c-no-irq' used to be a
> > bug in linux/i2c.h.)
> >
> > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
I just hit this while trying to get the at24 driver working. So:
Acked-by: Sean MacLennan <smaclennan@pikatech.com>
Cheers,
Sean
^ permalink raw reply
* Re: SW TLB MMU rework and SMP issues (pte read/write)
From: Kumar Gala @ 2008-07-16 22:12 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1216244518.7740.205.camel@pasglop>
On Jul 16, 2008, at 4:41 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2008-07-16 at 15:57 -0500, Kumar Gala wrote:
>> This makes sense. I think we need to order the stores in set_pte_at
>> regardless of CONFIG_SMP.
>
> Nah, that shouldn't be necessary.
Yeah I finally came to that realization.
>> Also, I think we should change pte_clear to
>> use pte_update() so we only clear the low-order flag bits. Patch
>> will
>> be sent shortly for review.
>
> Well... at one point at least we did rely on a PTE page with all PTEs
> cleared to be blank. It don't know if that's still the case, I need to
> look.
Doesn't look like we do anything special, we just call free_pages or
__free_pages in arch/powerpc/mm/pgtable_32.c.
- k
^ permalink raw reply
* Re: [i2c] [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
From: Grant Likely @ 2008-07-16 22:20 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080712080004.GA16739@pengutronix.de>
On Sat, Jul 12, 2008 at 2:00 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Fri, Jul 11, 2008 at 12:23:23PM -0600, Grant Likely wrote:
>> On Fri, Jul 11, 2008 at 09:48:59PM +0400, Anton Vorontsov wrote:
>> > Firstly kernel warns at set_irq_chip, and then dies completely:
>> >
>> > Trying to install chip for IRQ-1
>> >
>> > diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
>> > index b2ccdcb..95a24de 100644
>> > --- a/drivers/of/of_i2c.c
>> > +++ b/drivers/of/of_i2c.c
>> > @@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
>> > if (info.irq == NO_IRQ)
>> > info.irq = -1;
>>
>> What is the reason that info.irq is set to -1 in the first place? This
>> looks like another bug to me. Does something in the i2c layer depend on
>> the -1 value?
>>
>
> You already acked a fix to this :) I wasn't sure if my patch would
> make it on its own, as Jon Smirl was also working on fixes to of_i2c.c
> and he seemed to pick up this issue, too.
Ugh, I have trouble remembering what I've done from one day to the next. :-/
After looking at it again, I'm inclined to prefer the NO_IRQ fix.
There is a smaller user base of of_i2c and so it will have a much
smaller impact if it breaks stuff. It also has the added advantage of
encouraging people to actually fix the drivers that assume -1.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Fix wrong 'no interrupt' handling in of_i2c
From: Grant Likely @ 2008-07-16 22:22 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Wolfram Sang
In-Reply-To: <20080716181556.2974a1a8@lappy.seanm.ca>
On Wed, Jul 16, 2008 at 4:15 PM, Sean MacLennan <smaclennan@pikatech.com> wrote:
> On Sat, 28 Jun 2008 13:16:16 -0600
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
>> On Sat, Jun 28, 2008 at 12:31 PM, Wolfram Sang
>> <w.sang@pengutronix.de> wrote:
>> > If an I2C device node does not specify an interrupt, the .irq
>> > member of the board_info struct was set to -1. This caused crashes
>> > on following irq_dispose_mappings. Leave it NO_IRQ as returned from
>> > irq_of_parse_and_map. (Suggesting -1 as 'i2c-no-irq' used to be a
>> > bug in linux/i2c.h.)
>> >
>> > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
>>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>>
>
> I just hit this while trying to get the at24 driver working. So:
>
> Acked-by: Sean MacLennan <smaclennan@pikatech.com>
Okay, I'll pick this one up.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
From: Dave Jones @ 2008-07-16 22:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <37829F82-D71C-4B42-A752-DA86C6F2764D@kernel.crashing.org>
On Wed, Jul 16, 2008 at 05:10:29PM -0500, Kumar Gala wrote:
>
> On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
>
> > On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
> >> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
> >>> If we don't enable FS_ENET we get build issues:
> >>>
> >>> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> >>> arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
> >>> `alloc_mdio_bitbang'
> >>> arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to
> >>> `mdiobus_register'
> >>
> >> How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG.
> >
> > If CONFIG_PHYLIB=m however, that doesn't make any difference, because
> > vmlinuz is trying to use a symbol which now lives in a module.
>
> The mdiobus_register make sense, I'm not sure get why
> alloc_mdio_bitbang is undefined.
Erm, same reason. it's built into phy.o, which ends up in the module,
not the vmlinuz.
(also, it doesn't look like it's exported even if it was built-in?)
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
From: Kumar Gala @ 2008-07-16 22:23 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-kernel, linuxppc-dev, Scott Wood, Dave Jones, akpm,
torvalds
In-Reply-To: <37829F82-D71C-4B42-A752-DA86C6F2764D@kernel.crashing.org>
On Jul 16, 2008, at 5:10 PM, Kumar Gala wrote:
>
> On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
>
>> On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
>>> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
>>>> If we don't enable FS_ENET we get build issues:
>>>>
>>>> arch/powerpc/platforms/built-in.o: In function
>>>> `ep8248e_mdio_probe':
>>>> arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
>>>> `alloc_mdio_bitbang'
>>>> arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to
>>>> `mdiobus_register'
>>>
>>> How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG.
>>
>> If CONFIG_PHYLIB=m however, that doesn't make any difference, because
>> vmlinuz is trying to use a symbol which now lives in a module.
>
> The mdiobus_register make sense, I'm not sure get why
> alloc_mdio_bitbang is undefined.
nevermind, I now see why the libphy is being built.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: fix support for latencytop
From: Benjamin Herrenschmidt @ 2008-07-16 22:28 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <200807170012.25859.arnd@arndb.de>
On Thu, 2008-07-17 at 00:12 +0200, Arnd Bergmann wrote:
> We need to pass the kernel stack pointer instead of the user space
> stack pointer in save_stack_trace_tsk().
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> On Wednesday 16 July 2008, Nathan Lynch wrote:
> > Arnd Bergmann wrote:
> > > Implement save_stack_trace_tsk on powerpc, so that we can run with
> > > latencytop.
> >
> > So I tried latencytop with linux-next and got the following oops, but
> > I didn't really look into it yet.
>
> Oh, I didn't even realize that benh had merged that patch of mine.
> As I wrote in the description, it was entirely untested. You found
> another obvious bug: The code was passing the user space stack
> pointer instead of the kernel stack pointer.
>
> Again, this patch is entirely untested, and I would not be at all
> surprised to find other trivial bugs.
I missed that part of your description and it didn't seem to break the
kernel stack trace so ... :-) It's a nice feature to have and bugs can
be fixed before release.
Now we should probably look at making the stacktrace code a bit more
robust vs. wild pointers anyway.
> --- a/arch/powerpc/kernel/stacktrace.c
> +++ b/arch/powerpc/kernel/stacktrace.c
> @@ -59,6 +59,6 @@ EXPORT_SYMBOL_GPL(save_stack_trace);
>
> void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
> {
> - save_context_stack(trace, tsk->thread.regs->gpr[1], tsk, 0);
> + save_context_stack(trace, tsk->thread.ksp, tsk, 0);
> }
> EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
^ permalink raw reply
* Re: 82xx performance
From: Arnd Bergmann @ 2008-07-16 22:32 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, Milton Miller
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04B3499C@ismail.innsys.innovsys.com>
On Wednesday 16 July 2008, Rune Torgersen wrote:
> I did run oprofile, but I could not figure out how to get it to show me
> where in the kernel it was spending time. It showed that a lot of time
> was spent in vmlinux, but not anything specific. I probably just don't
> know how to set up or run oprofile correctly.
Maybe you passed no vmlinux, or only a stripped one?
Oprofile needs to have a vmlinux file to extract the symbol
information from.
If you can't get it to work, readprofile(1) is a much simpler
tool, both in what it can do and what it requires you to do.
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc: fix support for latencytop
From: Nathan Lynch @ 2008-07-16 22:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200807170012.25859.arnd@arndb.de>
Arnd Bergmann wrote:
> We need to pass the kernel stack pointer instead of the user space
> stack pointer in save_stack_trace_tsk().
Thanks, this fixes it, and latencytop even seems to work. :)
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
From: Kumar Gala @ 2008-07-16 22:55 UTC (permalink / raw)
To: Dave Jones; +Cc: Scott Wood, linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <20080716221949.GA18148@redhat.com>
On Jul 16, 2008, at 5:19 PM, Dave Jones wrote:
> On Wed, Jul 16, 2008 at 05:10:29PM -0500, Kumar Gala wrote:
>>
>> On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
>>
>>> On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
>>>> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
>>>>> If we don't enable FS_ENET we get build issues:
>>>>>
>>>>> arch/powerpc/platforms/built-in.o: In function
>>>>> `ep8248e_mdio_probe':
>>>>> arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
>>>>> `alloc_mdio_bitbang'
>>>>> arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to
>>>>> `mdiobus_register'
>>>>
>>>> How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG.
>>>
>>> If CONFIG_PHYLIB=m however, that doesn't make any difference,
>>> because
>>> vmlinuz is trying to use a symbol which now lives in a module.
>>
>> The mdiobus_register make sense, I'm not sure get why
>> alloc_mdio_bitbang is undefined.
>
> Erm, same reason. it's built into phy.o, which ends up in the module,
> not the vmlinuz.
>
> (also, it doesn't look like it's exported even if it was built-in?)
It looks like the simplest solution at this point is to
unconditionally select the PHYLIB for this board. We should look at
moving the low level mdio bitbang ops out so they can be built as a
module.
- k
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: Arnd Bergmann @ 2008-07-16 22:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Victor Gallardo, fkan, linuxppc-embedded
In-Reply-To: <20080716154646.GH24045@secretlab.ca>
On Wednesday 16 July 2008, Grant Likely wrote:
>=20
> > Shouldn't it be enough to have a common compatible value in each
> > of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
> > specific type unless you need to do something special?
>=20
> This is bad for the same reason that "amcc,44x-<blah>" compatible values
> are bad in device nodes. =A0The definition of '*-44x-*' changes over time=
as
> new parts are added. =A0Compatible values should always reflect an exact
> part number.
I agree in general, but I also think that all 44x boards should be
regarded as the same machine time, in the same way that all powermacs
are detected as compatible with "Power Macintosh" or "MacRISC", or
how all sorts of serial ports claim compatibility with i8250.
=46or classic SOCs like 4xx or 52xx, the SOC familiy more or less defines
the platform, and all the details about peripherals can be expressed
in the device tree elsewhere.
If one board is so different that you need a separate board setup
in the kernel, it should simply not claim compatibility with the
SOC platform.
Arnd <><
^ permalink raw reply
* [UPDATE][FOR 2.6.27] Please pull from 'powerpc-next' branch
From: Kumar Gala @ 2008-07-16 23:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next
Note: this tree is based on Linus's master as I need to revert a commit he
applied to the ep8248e board.
to receive the following updates:
Documentation/powerpc/booting-without-of.txt | 189 ++--
Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt | 38
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt | 53 -
Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt | 17
Documentation/powerpc/dts-bindings/fsl/pmc.txt | 63 +
Documentation/powerpc/dts-bindings/fsl/tsec.txt | 31
Documentation/powerpc/dts-bindings/fsl/upm-nand.txt | 28
Documentation/powerpc/dts-bindings/gpio/led.txt | 15
arch/powerpc/Kconfig | 14
arch/powerpc/boot/dts/mpc7448hpc2.dts | 24
arch/powerpc/boot/dts/mpc8313erdb.dts | 241 +++--
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 14
arch/powerpc/configs/85xx/mpc8544_ds_defconfig | 8
arch/powerpc/configs/85xx/mpc8572_ds_defconfig | 8
arch/powerpc/configs/mpc85xx_defconfig | 8
arch/powerpc/configs/mpc8610_hpcd_defconfig | 121 ++
arch/powerpc/configs/mpc8641_hpcn_defconfig | 8
arch/powerpc/kernel/head_fsl_booke.S | 187 +---
arch/powerpc/platforms/52xx/Kconfig | 1
arch/powerpc/platforms/82xx/Kconfig | 1
arch/powerpc/platforms/82xx/ep8248e.c | 4
arch/powerpc/platforms/83xx/Kconfig | 3
arch/powerpc/platforms/83xx/Makefile | 2
arch/powerpc/platforms/83xx/mpc831x_rdb.c | 1
arch/powerpc/platforms/83xx/mpc832x_mds.c | 1
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 1
arch/powerpc/platforms/83xx/mpc834x_itx.c | 1
arch/powerpc/platforms/83xx/mpc834x_mds.c | 1
arch/powerpc/platforms/83xx/mpc836x_mds.c | 1
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 1
arch/powerpc/platforms/83xx/mpc837x_mds.c | 1
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 1
arch/powerpc/platforms/83xx/mpc83xx.h | 5
arch/powerpc/platforms/83xx/pci.c | 91 --
arch/powerpc/platforms/83xx/sbc834x.c | 1
arch/powerpc/platforms/83xx/suspend-asm.S | 533 ++++++++++++
arch/powerpc/platforms/83xx/suspend.c | 388 ++++++++
arch/powerpc/platforms/83xx/usb.c | 24
arch/powerpc/platforms/85xx/Kconfig | 3
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 2
arch/powerpc/platforms/86xx/Kconfig | 3
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 87 -
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2
arch/powerpc/platforms/Kconfig | 6
arch/powerpc/platforms/Kconfig.cputype | 2
arch/powerpc/platforms/fsl_uli1575.c | 117 ++
arch/powerpc/platforms/iseries/Kconfig | 1
arch/powerpc/platforms/ps3/Kconfig | 1
arch/powerpc/platforms/pseries/Kconfig | 1
arch/powerpc/sysdev/fsl_pci.c | 61 +
arch/powerpc/sysdev/fsl_pci.h | 1
arch/powerpc/sysdev/fsl_soc.c | 90 --
arch/powerpc/sysdev/fsl_soc.h | 1
arch/powerpc/sysdev/ipic.c | 71 +
arch/powerpc/sysdev/qe_lib/qe.c | 6
arch/powerpc/sysdev/qe_lib/ucc.c | 6
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 16
drivers/net/fs_enet/Makefile | 5
drivers/net/fs_enet/fs_enet-main.c | 310 ------
drivers/net/fs_enet/fs_enet.h | 4
drivers/net/fs_enet/mac-fcc.c | 67 -
drivers/net/fs_enet/mac-fec.c | 23
drivers/net/fs_enet/mac-scc.c | 37
drivers/net/fs_enet/mii-bitbang.c | 107 --
drivers/net/fs_enet/mii-fec.c | 144 ---
drivers/net/gianfar.c | 122 ++
drivers/net/gianfar.h | 12
drivers/net/gianfar_ethtool.c | 41
include/asm-powerpc/pgtable-ppc32.h | 15
include/asm-powerpc/reg.h | 4
include/asm-powerpc/ucc_fast.h | 8
include/linux/fs_enet_pd.h | 4
include/linux/fsl_devices.h | 7
73 files changed, 2163 insertions(+), 1353 deletions(-)
Andy Fleming (2):
powerpc: Add support for multiple gfar mdio interfaces
powerpc: Fix a bunch of sparse warnings in the qe_lib
Anton Vorontsov (6):
powerpc/83xx: fix ULPI setup for MPC8315 processors
powerpc/fsl_soc: gianfar: don't probe disabled devices
powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
powerpc/fsl_uli1575: fix RTC quirk to work on MPC8572DS and MPC8610HPCD
powerpc/85xx/86xx: some refactoring for fsl_uli1575 code
powerpc/86xx: mpc8610_hpcd - add support for ULI RTC
Jochen Friedrich (1):
powerpc: Add documentation for CPM GPIO banks
John Rigby (2):
powerpc: pci config cleanup
powerpc: Move mpc83xx_add_bridge to fsl_pci.c
Kumar Gala (6):
fs_enet: Remove !CONFIG_PPC_CPM_NEW_BINDING code
powerpc: Remove Kconfig PPC_CPM_NEW_BINDING
powerpc: rework FSL Book-E PTE access and TLB miss
powerpc/fsl: Minor TLBSYNC cleanup for FSL Book-E
powerpc/ep8248e: Unconditionally select PHYLIB for mdio_bitbang
Revert "powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET"
Paul Gortmaker (1):
powerpc/mpc7448: add alias list to DTS, clean out old chosen node
Scott Wood (6):
powerpc: Document Freescale power management nodes, and the sleep property.
powerpc: Update example SOC node in booting-without-of.txt.
powerpc/mpc83xx: Power Management support
powerpc/mpc8313erdb: Add power management to the device tree.
gianfar: Add magic packet and suspend/resume support.
Add fsl,magic-packet to, and clean up, the gianfar binding.
Timur Tabi (1):
powerpc: fix ALSA options in Freescale 85xx and 86xx defconfigs
^ permalink raw reply
* [PATCH] powerpc/ep8248e: Unconditionally select PHYLIB for mdio_bitbang
From: Kumar Gala @ 2008-07-16 23:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: davej, akpm, torvalds, linux-kernel
Its possible to build the phylib as a module, however this breaks the
board code because alloc_mdio_bitbang and mdiobus_register are not
available if we build as a module. These are needed by the board code
since it implements the low level mdio bitbang ops.
So we unconditionally select PHYLIB to ensure its built into the kernel
if we are building in EP8248E support.
Long term we should look at moving the mdio_ops into its own file so it
can be built as a module.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
This patch supercededs:
[PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
I've reverted the old patch and applied the new patch in my git tree and
have asked Ben to pull and push it to Linus.
- k
arch/powerpc/platforms/82xx/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
index 1c8034b..75eb1ed 100644
--- a/arch/powerpc/platforms/82xx/Kconfig
+++ b/arch/powerpc/platforms/82xx/Kconfig
@@ -30,6 +30,7 @@ config EP8248E
select 8272
select 8260
select FSL_SOC
+ select PHYLIB
select MDIO_BITBANG
help
This enables support for the Embedded Planet EP8248E board.
--
1.5.5.1
^ permalink raw reply related
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Trent Piepho @ 2008-07-16 23:18 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Stephen Rothwell, Richard Purdie, linux-kernel
In-Reply-To: <20080715151917.GA30607@polina.dev.rtsoft.ru>
On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> is not much code can be shared between the two drivers (both are mostly
> driver bindings anyway).
Why can't this driver use the existing gpio-led driver? Basically, do
something like this:
of_gpio_leds_probe(...)
{
gpio = of_get_gpio(np, 0);
label = of_get_property(np, "label", NULL);
struct gpio_led led = {
.name = label,
.gpio = gpio,
};
pdev = platform_device_register_simple("leds-gpio", 0, NULL, 0);
platform_device_add_data(pdev, &led, sizeof(led));
}
^ permalink raw reply
* [PATCH 1/6] crypto: talitos - remove calls to of_node_put
From: Kim Phillips @ 2008-07-16 23:21 UTC (permalink / raw)
To: linux-crypto; +Cc: linuxppc-dev, Herbert Xu
From: Lee Nipper <lee.nipper@freescale.com>
Remove of_node_put calls since there is no corresponding of_node_get.
This patch prevents an exception when talitos is loaded a 2nd time.
This sequence: modprobe talitos; rmmod talitos; modprobe talitos
causes this message: "WARNING: Bad of_node_put() on /soc8349@e0000000/crypto@30000".
Signed-off-by: Lee Nipper <lee.nipper@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
this patchseries contains various fixes to the talitos driver, mainly as a
result of Lee's stress testing.
drivers/crypto/talitos.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index b11943d..01e6595 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1466,9 +1466,6 @@ static int talitos_probe(struct of_device *ofdev,
goto err_out;
}
- of_node_put(np);
- np = NULL;
-
priv->head_lock = kmalloc(sizeof(spinlock_t) * priv->num_channels,
GFP_KERNEL);
priv->tail_lock = kmalloc(sizeof(spinlock_t) * priv->num_channels,
@@ -1559,8 +1556,6 @@ static int talitos_probe(struct of_device *ofdev,
err_out:
talitos_remove(ofdev);
- if (np)
- of_node_put(np);
return err;
}
--
1.5.6
^ permalink raw reply related
* [PATCH 2/6] crypto: talitos - correct dst != src case handling
From: Kim Phillips @ 2008-07-16 23:21 UTC (permalink / raw)
To: linux-crypto; +Cc: linuxppc-dev, Herbert Xu
From: Lee Nipper <lee.nipper@freescale.com>
Seems that dst == src, but this fixes the logic in case it's not.
Signed-off-by: Lee Nipper <lee.nipper@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
drivers/crypto/talitos.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 01e6595..f644fba 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1022,7 +1022,7 @@ static struct ipsec_esp_edesc *ipsec_esp_edesc_alloc(struct aead_request *areq,
dst_nents = src_nents;
} else {
dst_nents = sg_count(areq->dst, areq->cryptlen + ctx->authsize);
- dst_nents = (dst_nents == 1) ? 0 : src_nents;
+ dst_nents = (dst_nents == 1) ? 0 : dst_nents;
}
/*
--
1.5.6
^ permalink raw reply related
* [PATCH 3/6] crypto: talitos - preempt overflow interrupts
From: Kim Phillips @ 2008-07-16 23:21 UTC (permalink / raw)
To: linux-crypto; +Cc: linuxppc-dev, Herbert Xu
add requests pending/submit count to prevent request queue full
condition by preempting h/w overflow interrupts in software.
We do this due to the delay in the delivery and handling of the
channel overflow error interrupt.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Acked-by: Lee Nipper <lee.nipper@freescale.com>
---
drivers/crypto/talitos.c | 27 ++++++++++++++++++++++-----
1 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index f644fba..fdb0680 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -99,6 +99,9 @@ struct talitos_private {
/* next channel to be assigned next incoming descriptor */
atomic_t last_chan;
+ /* per-channel number of requests pending in channel h/w fifo */
+ atomic_t *submit_count;
+
/* per-channel request fifo */
struct talitos_request **fifo;
@@ -263,15 +266,15 @@ static int talitos_submit(struct device *dev, struct talitos_desc *desc,
spin_lock_irqsave(&priv->head_lock[ch], flags);
- head = priv->head[ch];
- request = &priv->fifo[ch][head];
-
- if (request->desc) {
- /* request queue is full */
+ if (!atomic_inc_not_zero(&priv->submit_count[ch])) {
+ /* h/w fifo is full */
spin_unlock_irqrestore(&priv->head_lock[ch], flags);
return -EAGAIN;
}
+ head = priv->head[ch];
+ request = &priv->fifo[ch][head];
+
/* map descriptor and save caller data */
request->dma_desc = dma_map_single(dev, desc, sizeof(*desc),
DMA_BIDIRECTIONAL);
@@ -335,6 +338,9 @@ static void flush_channel(struct device *dev, int ch, int error, int reset_ch)
priv->tail[ch] = (tail + 1) & (priv->fifo_len - 1);
spin_unlock_irqrestore(&priv->tail_lock[ch], flags);
+
+ atomic_dec(&priv->submit_count[ch]);
+
saved_req.callback(dev, saved_req.desc, saved_req.context,
status);
/* channel may resume processing in single desc error case */
@@ -1337,6 +1343,7 @@ static int __devexit talitos_remove(struct of_device *ofdev)
if (hw_supports(dev, DESC_HDR_SEL0_RNG))
talitos_unregister_rng(dev);
+ kfree(priv->submit_count);
kfree(priv->tail);
kfree(priv->head);
@@ -1501,6 +1508,16 @@ static int talitos_probe(struct of_device *ofdev,
}
}
+ priv->submit_count = kmalloc(sizeof(int) * priv->num_channels,
+ GFP_KERNEL);
+ if (!priv->submit_count) {
+ dev_err(dev, "failed to allocate fifo submit count space\n");
+ err = -ENOMEM;
+ goto err_out;
+ }
+ for (i = 0; i < priv->num_channels; i++)
+ atomic_set(&priv->submit_count[i], -priv->chfifo_len);
+
priv->head = kzalloc(sizeof(int) * priv->num_channels, GFP_KERNEL);
priv->tail = kzalloc(sizeof(int) * priv->num_channels, GFP_KERNEL);
if (!priv->head || !priv->tail) {
--
1.5.6
^ permalink raw reply related
* [PATCH 4/6] crypto: talitos - fix GFP flag usage
From: Kim Phillips @ 2008-07-16 23:22 UTC (permalink / raw)
To: linux-crypto; +Cc: linuxppc-dev, Herbert Xu
use GFP_ATOMIC when necessary; use atomic_t when allocating submit_count.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Acked-by: Lee Nipper <lee.nipper@freescale.com>
---
drivers/crypto/talitos.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index fdb0680..79fdba2 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1015,6 +1015,8 @@ static struct ipsec_esp_edesc *ipsec_esp_edesc_alloc(struct aead_request *areq,
struct talitos_ctx *ctx = crypto_aead_ctx(authenc);
struct ipsec_esp_edesc *edesc;
int src_nents, dst_nents, alloc_len, dma_len;
+ gfp_t flags = areq->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ? GFP_KERNEL :
+ GFP_ATOMIC;
if (areq->cryptlen + ctx->authsize > TALITOS_MAX_DATA_LEN) {
dev_err(ctx->dev, "cryptlen exceeds h/w max limit\n");
@@ -1046,7 +1048,7 @@ static struct ipsec_esp_edesc *ipsec_esp_edesc_alloc(struct aead_request *areq,
alloc_len += icv_stashing ? ctx->authsize : 0;
}
- edesc = kmalloc(alloc_len, GFP_DMA);
+ edesc = kmalloc(alloc_len, GFP_DMA | flags);
if (!edesc) {
dev_err(ctx->dev, "could not allocate edescriptor\n");
return ERR_PTR(-ENOMEM);
@@ -1508,7 +1510,7 @@ static int talitos_probe(struct of_device *ofdev,
}
}
- priv->submit_count = kmalloc(sizeof(int) * priv->num_channels,
+ priv->submit_count = kmalloc(sizeof(atomic_t) * priv->num_channels,
GFP_KERNEL);
if (!priv->submit_count) {
dev_err(dev, "failed to allocate fifo submit count space\n");
--
1.5.6
^ permalink raw reply related
* [PATCH 5/6] crypto: talitos - stop leaking memory in error path
From: Kim Phillips @ 2008-07-16 23:22 UTC (permalink / raw)
To: linux-crypto; +Cc: linuxppc-dev, Herbert Xu
free edescriptor when returning error (such as -EAGAIN).
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Acked-by: Lee Nipper <lee.nipper@freescale.com>
---
drivers/crypto/talitos.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 79fdba2..a81265b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -880,7 +880,7 @@ static int ipsec_esp(struct ipsec_esp_edesc *edesc, struct aead_request *areq,
unsigned int cryptlen = areq->cryptlen;
unsigned int authsize = ctx->authsize;
unsigned int ivsize;
- int sg_count;
+ int sg_count, ret;
/* hmac key */
map_single_talitos_ptr(dev, &desc->ptr[0], ctx->authkeylen, &ctx->key,
@@ -984,7 +984,12 @@ static int ipsec_esp(struct ipsec_esp_edesc *edesc, struct aead_request *areq,
map_single_talitos_ptr(dev, &desc->ptr[6], ivsize, ctx->iv, 0,
DMA_FROM_DEVICE);
- return talitos_submit(dev, desc, callback, areq);
+ ret = talitos_submit(dev, desc, callback, areq);
+ if (ret != -EINPROGRESS) {
+ ipsec_esp_unmap(dev, edesc, areq);
+ kfree(edesc);
+ }
+ return ret;
}
--
1.5.6
^ permalink raw reply related
* Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
From: Trent Piepho @ 2008-07-16 23:22 UTC (permalink / raw)
To: Richard Purdie; +Cc: linuxppc-dev, Stephen Rothwell, linux-kernel
In-Reply-To: <1216133032.5345.73.camel@dax.rpnet.com>
On Tue, 15 Jul 2008, Richard Purdie wrote:
> On Tue, 2008-07-15 at 18:23 +0400, Anton Vorontsov wrote:
>>> Spell out openfirmware :). I initially had no idea "of == openfirmware"
>>> and I suspect others won't either...
>>
>> This would be unusually long name, that is
>>
>> $ find . -iname '*openfirmware*' | wc -l
>> 0
>>
>> And in contrast:
>>
>> drivers/video/offb.c
>> drivers/video/nvidia/nv_of.c
>> drivers/usb/host/ohci-ppc-of.c
>> drivers/usb/host/ehci-ppc-of.c
>> drivers/serial/of_serial.c
>> drivers/mtd/maps/physmap_of.c
>> ...
>>
>> So, I think we should stick with the "of" for consistency, while
>> confused users may consult with Kconfig for disambiguation.
>
> The other cases don't have a gpio driver to confuse this new driver
> with. Lets spell it out please, the filesystems can handle the extra
> letters :).
There's drivers/mtd/maps/physmap.c and drivers/mtd/maps/physmap_of.c,
drivers/serial/of_serial.c and drivers/serial/serial_core.c,
drivers/usb/host/ehci-ppc-soc.c and drivers/usb/host/ehci-ppc-of.c, etc.
^ permalink raw reply
* [PATCH 6/6] crypto: talitos - sparse fix
From: Kim Phillips @ 2008-07-16 23:22 UTC (permalink / raw)
To: linux-crypto; +Cc: linuxppc-dev, Herbert Xu
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
drivers/crypto/talitos.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index a81265b..681c15f 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -848,7 +848,7 @@ static int sg_to_link_tbl(struct scatterlist *sg, int sg_count,
/* adjust (decrease) last one (or two) entry's len to cryptlen */
link_tbl_ptr--;
- while (link_tbl_ptr->len <= (-cryptlen)) {
+ while (be16_to_cpu(link_tbl_ptr->len) <= (-cryptlen)) {
/* Empty this entry, and move to previous one */
cryptlen += be16_to_cpu(link_tbl_ptr->len);
link_tbl_ptr->len = 0;
--
1.5.6
^ permalink raw reply related
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