* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Michael Neuling @ 2009-12-17 9:57 UTC (permalink / raw)
To: Mahesh Jagannath Salgaonkar; +Cc: linuxppc-dev, Masami Hiramatsu
In-Reply-To: <4B29EE5F.9020801@linux.vnet.ibm.com>
In message <4B29EE5F.9020801@linux.vnet.ibm.com> you wrote:
> Hi Michael,
>
> Michael Neuling wrote:
> >> Index: linux-2.6-tip/arch/powerpc/include/asm/ptrace.h
> >> ===================================================================
> >> --- linux-2.6-tip.orig/arch/powerpc/include/asm/ptrace.h
> >> +++ linux-2.6-tip/arch/powerpc/include/asm/ptrace.h
> >> @@ -83,6 +83,7 @@ struct pt_regs {
> >>
> >> #define instruction_pointer(regs) ((regs)->nip)
> >> #define user_stack_pointer(regs) ((regs)->gpr[1])
> >> +#define kernel_stack_pointer(regs) ((regs)->gpr[1])
> >> #define regs_return_value(regs) ((regs)->gpr[3])
> >>
> >> #ifdef CONFIG_SMP
> >> @@ -131,6 +132,69 @@ do {
> > \
> >> } while (0)
> >> #endif /* __powerpc64__ */
> >>
> >> +/* Query offset/name of register from its name/offset */
> >> +#include <linux/stddef.h>
> >> +#include <linux/thread_info.h>
> >
> > Includes should be at the start of the file
> >
> The compilation throws many errors when moved to start of the file. This
> file has lots of #ifdef and found this place to be perfect for compilation.
Ok, no problem.
>
> >> +/**
> >> + * regs_query_register_name() - query register name from its offset
> >> + * @offset: the offset of a register in struct pt_regs.
> >> + *
> >> + * regs_query_register_name() returns the name of a register from its
> >> + * offset in struct pt_regs. If the @offset is invalid, this returns NULL
;
> >> + */
> >> +const char *regs_query_register_name(unsigned int offset)
> >> +{
> >> + const struct pt_regs_offset *roff;
> >> + for (roff = regoffset_table; roff->name != NULL; roff++)
> >> + if (roff->offset == offset)
> >> + return roff->name;
> >> + return NULL;
> >> +}
> >> +
> >> +static const int arg_offs_table[] = {
> >> + [0] = offsetof(struct pt_regs, gpr[3]),
> >> + [1] = offsetof(struct pt_regs, gpr[4]),
> >> + [2] = offsetof(struct pt_regs, gpr[5]),
> >> + [3] = offsetof(struct pt_regs, gpr[6]),
> >> + [4] = offsetof(struct pt_regs, gpr[7]),
> >> + [5] = offsetof(struct pt_regs, gpr[8]),
> >> + [6] = offsetof(struct pt_regs, gpr[9]),
> >> + [7] = offsetof(struct pt_regs, gpr[10])
> >> +};
> >> +
> >> +/**
> >> + * regs_get_argument_nth() - get Nth argument at function call
> >> + * @regs: pt_regs which contains registers at function entry.
> >> + * @n: argument number.
> >> + *
> >> + * regs_get_argument_nth() returns @n th argument of a function call.
> >> + * Since usually the kernel stack will be changed right after function en
try
> > ,
> >> + * you must use this at function entry. If the @n th entry is NOT in the
> >> + * kernel stack or pt_regs, this returns 0.
> >> + */
> >> +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned int n)
> >> +{
> >> + if (n < ARRAY_SIZE(arg_offs_table))
> >> + return *(unsigned long *)((char *)regs + arg_offs_table[n]);
> >> + else {
> >> + /*
> >> + * If more arguments are passed that can be stored in
> >> + * registers, the remaining arguments are stored in the
> >> + * parameter save area located at fixed offset from stack
> >> + * pointer.
> >> + * Following the PowerPC ABI, the first few arguments are
> >> + * actually passed in registers (r3-r10), with equivalent space
> >> + * left unused in the parameter save area.
> >> + */
> >> + n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
> >> + return regs_get_kernel_stack_nth(regs, n);
> >
> > How do we handle FP args?
>
> Currently this patch does not support FP args.
This might be OK. I don't think we use floating point parameters in any
function definitions in the kernel.
We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
they are static inline, so they probably don't even end up as
functions.
I guess we need to make sure that we're not limiting the interface in
such a way that we can't support it later if the above changes.
regs_get_argument_nth returns an unsigned long which makes returning a
128 bit VMX register impossible. This might be a show stopper for me.
How are the x86 guys dealing with this?
> >
> >> + }
> >> +}
> >> +/*
> >> * does not yet catch signals sent when the child dies.
> >> * in exit.c or in signal.c.
> >> */
> >> Index: linux-2.6-tip/kernel/trace/Kconfig
> >> ===================================================================
> >> --- linux-2.6-tip.orig/kernel/trace/Kconfig
> >> +++ linux-2.6-tip/kernel/trace/Kconfig
> >> @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
> >>
> >> config KPROBE_EVENT
> >> depends on KPROBES
> >> - depends on X86
> >> + depends on X86 || PPC
> >> bool "Enable kprobes-based dynamic events"
> >> select TRACING
> >> default y
> >>
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>
>
> Thanks for reviewing.
We are creating a new user space API here, so I'm keen for others to take
a good look at the interface before we commit to something we are going
to have to keep forever.
Who is the main consumer of this (/me is pretty ignorant of kprobes)?
What do they think of the interface?
Mikey
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Michael Neuling @ 2009-12-17 9:43 UTC (permalink / raw)
To: Masami Hiramatsu; +Cc: Mahesh Salgaonkar, linuxppc-dev
In-Reply-To: <4B29C3E3.3060905@redhat.com>
In message <4B29C3E3.3060905@redhat.com> you wrote:
> Hi Michael,
>
> Michael Neuling wrote:
> >> +
> >> +static const struct pt_regs_offset regoffset_table[] = {
> >> + REG_OFFSET_NAME(gpr[0]),
> >> + REG_OFFSET_NAME(gpr[1]),
> >> + REG_OFFSET_NAME(gpr[2]),
> >> + REG_OFFSET_NAME(gpr[3]),
> >> + REG_OFFSET_NAME(gpr[4]),
> >> + REG_OFFSET_NAME(gpr[5]),
> >> + REG_OFFSET_NAME(gpr[6]),
> >> + REG_OFFSET_NAME(gpr[7]),
> >> + REG_OFFSET_NAME(gpr[8]),
> >> + REG_OFFSET_NAME(gpr[9]),
> >> + REG_OFFSET_NAME(gpr[10]),
> >> + REG_OFFSET_NAME(gpr[11]),
> >> + REG_OFFSET_NAME(gpr[12]),
> >> + REG_OFFSET_NAME(gpr[13]),
> >> + REG_OFFSET_NAME(gpr[14]),
> >> + REG_OFFSET_NAME(gpr[15]),
> >> + REG_OFFSET_NAME(gpr[16]),
> >> + REG_OFFSET_NAME(gpr[17]),
> >> + REG_OFFSET_NAME(gpr[18]),
> >> + REG_OFFSET_NAME(gpr[19]),
> >> + REG_OFFSET_NAME(gpr[20]),
> >> + REG_OFFSET_NAME(gpr[21]),
> >> + REG_OFFSET_NAME(gpr[22]),
> >> + REG_OFFSET_NAME(gpr[23]),
> >> + REG_OFFSET_NAME(gpr[24]),
> >> + REG_OFFSET_NAME(gpr[25]),
> >> + REG_OFFSET_NAME(gpr[26]),
> >> + REG_OFFSET_NAME(gpr[27]),
> >> + REG_OFFSET_NAME(gpr[28]),
> >> + REG_OFFSET_NAME(gpr[29]),
> >> + REG_OFFSET_NAME(gpr[30]),
> >> + REG_OFFSET_NAME(gpr[31]),
> >> + REG_OFFSET_NAME(nip),
> >> + REG_OFFSET_NAME(msr),
> >> + REG_OFFSET_NAME(orig_gpr3),
> >> + REG_OFFSET_NAME(ctr),
> >> + REG_OFFSET_NAME(link),
> >> + REG_OFFSET_NAME(xer),
> >> + REG_OFFSET_NAME(ccr),
> >> +#ifdef CONFIG_PPC64
> >> + REG_OFFSET_NAME(softe),
> >> +#else
> >> + REG_OFFSET_NAME(mq),
> >> +#endif
> >> + REG_OFFSET_NAME(trap),
> >> + REG_OFFSET_NAME(dar),
> >> + REG_OFFSET_NAME(dsisr),
> >> + REG_OFFSET_NAME(result),
> >> + REG_OFFSET_END,
> >
> > Do we need to add something for FP and VMX registers here?
>
> Hmm, are FP and VMX registers actually used inside kernel on PPC?
Yes. Look for enable_kernel_fp/altivec
Mikey
> Actually, the main purpose of this code is to provide accessing method
> of in-kernel pt_regs fields (registers used in kernel) by name.
^ permalink raw reply
* Re: [POWERPC] add U-Boot bootcount driver.
From: Wolfram Sang @ 2009-12-17 9:34 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20091216024730.455b90fd@vitb-lp>
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
On Wed, Dec 16, 2009 at 02:47:30AM +0300, Vitaly Bordug wrote:
>
> From: Heiko Schocher <hs@denx.de>
>
> This driver provides (read/write) access to the
> U-Boot bootcounter via PROC FS or sysFS.
>
> in u-boot, it uses a 8 byte mem area (it must hold the value over a
> soft reset of course), for storing a bootcounter (it counts many soft
> resets are done, on hard reset it starts with 0). If the bootcountvalue
> exceeds the value in the env variable "bootlimit", and alternative
> bootcmd stored in the env variable "altbootcmd" is run.
Hmm, both in my inbox and in patchwork, the patch seems line-wrapped.
Also, there are a few printk without loglevel. As probe has access to
a device structure, dev_* should be a nice option here.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Mahajan Vivek-B08308 @ 2009-12-17 8:59 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <4B29F23A.9070001@embedded-sol.com>
> From: Felix Radensky [mailto:felix@embedded-sol.com]=20
> Sent: Thursday, December 17, 2009 2:26 PM
> >
> Yes, I've enabled that bit, but didn't get any interrupt.
Thanks for trying.=20
>=20
> Thanks a lot. If I understand you correctly, the only way I=20
> can get ath9k driver to work on this board using legacy=20
> interrupts is to wait for a hardware fix. Right ?
Correct
>=20
> Felix.
>=20
Thanks,
Vivek
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky @ 2009-12-17 8:56 UTC (permalink / raw)
To: Mahajan Vivek-B08308; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <0949C49693EF1A47A54B0F0113CDB4A60767E8@zin33exm23.fsl.freescale.net>
Mahajan Vivek-B08308 wrote:
>> From:
>> linuxppc-dev-bounces+vivek.mahajan=freescale.com@lists.ozlabs.
>> org
>> [mailto:linuxppc-dev-bounces+vivek.mahajan=freescale.com@lists
>> .ozlabs.org] On Behalf Of Felix Radensky
>> Sent: Thursday, December 17, 2009 12:52 PM
>>
>>> I just noticed a MSI enable bit in
>>> drivers/net/wireless/ath/ath9k/reg.h
>>> as under, may be we need to trun this on:-
>>>
>>> reg.h:1013:#define AR_PCIE_MSI 0x4094
>>> reg.h:1014:#define AR_PCIE_MSI_ENABLE
>>>
>> 0x00000001
>>
>>>
>>>
>> According to ath9k developers adding MSI support to the
>> driver is not trivial.
>> They've tried once, it didn't work and they gave up. Any
>> chance I can use mini-PCI-E slot without MSI ?
>>
>
> So, even after enabling the above bit, there were no MSI
> interrupts from this card. If we look at some of the GbE
> or SATA drivers, adding MSI is not that hard. ath9k can
> be an exception.
>
Yes, I've enabled that bit, but didn't get any interrupt.
> I reported this issue to the p2020 board designer; but
> unfortunately he is out until 1/4/10. It could be a missing
> pull-up issue at IRQ0 or some thing else, I don't know.
>
>
Thanks a lot. If I understand you correctly, the only way I can
get ath9k driver to work on this board using legacy interrupts is
to wait for a hardware fix. Right ?
Felix.
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Mahesh Jagannath Salgaonkar @ 2009-12-17 8:39 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Masami Hiramatsu
In-Reply-To: <13884.1261016575@neuling.org>
Hi Michael,
Michael Neuling wrote:
>> Index: linux-2.6-tip/arch/powerpc/include/asm/ptrace.h
>> ===================================================================
>> --- linux-2.6-tip.orig/arch/powerpc/include/asm/ptrace.h
>> +++ linux-2.6-tip/arch/powerpc/include/asm/ptrace.h
>> @@ -83,6 +83,7 @@ struct pt_regs {
>>
>> #define instruction_pointer(regs) ((regs)->nip)
>> #define user_stack_pointer(regs) ((regs)->gpr[1])
>> +#define kernel_stack_pointer(regs) ((regs)->gpr[1])
>> #define regs_return_value(regs) ((regs)->gpr[3])
>>
>> #ifdef CONFIG_SMP
>> @@ -131,6 +132,69 @@ do {
> \
>> } while (0)
>> #endif /* __powerpc64__ */
>>
>> +/* Query offset/name of register from its name/offset */
>> +#include <linux/stddef.h>
>> +#include <linux/thread_info.h>
>
> Includes should be at the start of the file
>
The compilation throws many errors when moved to start of the file. This
file has lots of #ifdef and found this place to be perfect for compilation.
>> +/**
>> + * regs_query_register_name() - query register name from its offset
>> + * @offset: the offset of a register in struct pt_regs.
>> + *
>> + * regs_query_register_name() returns the name of a register from its
>> + * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
>> + */
>> +const char *regs_query_register_name(unsigned int offset)
>> +{
>> + const struct pt_regs_offset *roff;
>> + for (roff = regoffset_table; roff->name != NULL; roff++)
>> + if (roff->offset == offset)
>> + return roff->name;
>> + return NULL;
>> +}
>> +
>> +static const int arg_offs_table[] = {
>> + [0] = offsetof(struct pt_regs, gpr[3]),
>> + [1] = offsetof(struct pt_regs, gpr[4]),
>> + [2] = offsetof(struct pt_regs, gpr[5]),
>> + [3] = offsetof(struct pt_regs, gpr[6]),
>> + [4] = offsetof(struct pt_regs, gpr[7]),
>> + [5] = offsetof(struct pt_regs, gpr[8]),
>> + [6] = offsetof(struct pt_regs, gpr[9]),
>> + [7] = offsetof(struct pt_regs, gpr[10])
>> +};
>> +
>> +/**
>> + * regs_get_argument_nth() - get Nth argument at function call
>> + * @regs: pt_regs which contains registers at function entry.
>> + * @n: argument number.
>> + *
>> + * regs_get_argument_nth() returns @n th argument of a function call.
>> + * Since usually the kernel stack will be changed right after function entry
> ,
>> + * you must use this at function entry. If the @n th entry is NOT in the
>> + * kernel stack or pt_regs, this returns 0.
>> + */
>> +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned int n)
>> +{
>> + if (n < ARRAY_SIZE(arg_offs_table))
>> + return *(unsigned long *)((char *)regs + arg_offs_table[n]);
>> + else {
>> + /*
>> + * If more arguments are passed that can be stored in
>> + * registers, the remaining arguments are stored in the
>> + * parameter save area located at fixed offset from stack
>> + * pointer.
>> + * Following the PowerPC ABI, the first few arguments are
>> + * actually passed in registers (r3-r10), with equivalent space
>> + * left unused in the parameter save area.
>> + */
>> + n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
>> + return regs_get_kernel_stack_nth(regs, n);
>
> How do we handle FP args?
Currently this patch does not support FP args.
>
>> + }
>> +}
>> +/*
>> * does not yet catch signals sent when the child dies.
>> * in exit.c or in signal.c.
>> */
>> Index: linux-2.6-tip/kernel/trace/Kconfig
>> ===================================================================
>> --- linux-2.6-tip.orig/kernel/trace/Kconfig
>> +++ linux-2.6-tip/kernel/trace/Kconfig
>> @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
>>
>> config KPROBE_EVENT
>> depends on KPROBES
>> - depends on X86
>> + depends on X86 || PPC
>> bool "Enable kprobes-based dynamic events"
>> select TRACING
>> default y
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
Thanks for reviewing.
Thanks,
-Mahesh.
^ permalink raw reply
* Re: [POWERPC] add U-Boot bootcount driver.
From: Wolfgang Denk @ 2009-12-17 8:16 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20091216024730.455b90fd@vitb-lp>
Dear Vitaly Bordug,
repl: bad addresses:
linuxppc-dev@ozlabs.org <linuxppc-dev@ozlabs.org> -- junk after local@domain (<)
In message <20091216024730.455b90fd@vitb-lp> you wrote:
>
> From: Heiko Schocher <hs@denx.de>
>
> This driver provides (read/write) access to the
> U-Boot bootcounter via PROC FS or sysFS.
>
> in u-boot, it uses a 8 byte mem area (it must hold the value over a
> soft reset of course), for storing a bootcounter (it counts many soft
> resets are done, on hard reset it starts with 0). If the bootcountvalue
> exceeds the value in the env variable "bootlimit", and alternative
> bootcmd stored in the env variable "altbootcmd" is run.
>
> The bootcountregister gets configured via DTS.
> for example on the mgsuvd board:
>
> bootcount@0x3eb0 {
> device_type = "bootcount";
> compatible = "uboot,bootcount";
> reg = <0x3eb0 0x08>;
> };
>
> This driver is tested on the mgcoge(82xx) and mgsuvd(8xx) board.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Signed-off-by: Vitaly Bordyug <vitb@kernel.crashing.org>
I think it would be good if the text of the commit message could be
reworked by a native English speaker.
Regarding the subject: it is probably important to point out that this
driver implements the Linux kernel half of the boot count feature -
the boot counter can only be reset after it is clear that the
application has been started and is running correctly, which usually
can only be determined by the application code itself. Thus the reset
of the boot counter must be done by application code, which thus needs
an appropriate driver.
> I think there is no reason not to have this in mainline. Thoughts? And
> I'm not sure what is right direction to push this - it's representation
> of u-boot feature in fact, pretty useful tho.
It's not only useful, it's actually a required feature by the Carrier
Grade Linux Requirements Definition; see for example document "Carrier
Grade Linux Requirements Definition Overview V3.0" at
https://www.linux-foundation.org/images/1/1a/Cgl_req_def_overview_30.pdf
Page 49:
ID PLT.4.0 (2.3 in v1.1) Boot Cycle Detection
Description: OSDL CGL specifies that carrier grade Linux
shall provide support for detecting a repeating reboot cycle
due to recurring failures and going to an offline state if
this occurs.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I read part of it all the way through.
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Mahajan Vivek-B08308 @ 2009-12-17 7:59 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <4B29DC2B.8090405@embedded-sol.com>
> From:=20
> linuxppc-dev-bounces+vivek.mahajan=3Dfreescale.com@lists.ozlabs.
> org=20
> [mailto:linuxppc-dev-bounces+vivek.mahajan=3Dfreescale.com@lists
> .ozlabs.org] On Behalf Of Felix Radensky
> Sent: Thursday, December 17, 2009 12:52 PM
> >
> > I just noticed a MSI enable bit in=20
> > drivers/net/wireless/ath/ath9k/reg.h
> > as under, may be we need to trun this on:-
> >
> > reg.h:1013:#define AR_PCIE_MSI 0x4094
> > reg.h:1014:#define AR_PCIE_MSI_ENABLE =20
> 0x00000001
> > =20
> According to ath9k developers adding MSI support to the=20
> driver is not trivial.
> They've tried once, it didn't work and they gave up. Any=20
> chance I can use mini-PCI-E slot without MSI ?
So, even after enabling the above bit, there were no MSI=20
interrupts from this card. If we look at some of the GbE=20
or SATA drivers, adding MSI is not that hard. ath9k can=20
be an exception.=20
I reported this issue to the p2020 board designer; but=20
unfortunately he is out until 1/4/10. It could be a missing=20
pull-up issue at IRQ0 or some thing else, I don't know.=20
>=20
> Thanks.
>=20
> Felix.
Thanks,
Vivek
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky @ 2009-12-17 7:22 UTC (permalink / raw)
To: Mahajan Vivek-B08308; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <0949C49693EF1A47A54B0F0113CDB4A6076791@zin33exm23.fsl.freescale.net>
Hi,
Mahajan Vivek-B08308 wrote:
>>
>> I've enabled MSI in ath9k driver, by simply adding
>> pci_enable_msi() and
>> pci_disable_msi() at relevant places. The MSI interrupt is allocated.
>>
>> irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to virtual irq 18
>> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:
>> mem=0xf2160000, irq=18
>>
>> cat /proc/interrupts
>> CPU0
>> 18: 0 FSL-MSI Edge ath9k
>>
>> lspci -v shows that MSI was enabled on device
>>
>> But I don't get any interrupts. I've posted a question to
>> ath9k list, maybe folks there will have some ideas.
>>
>
> I just noticed a MSI enable bit in drivers/net/wireless/ath/ath9k/reg.h
> as under, may be we need to trun this on:-
>
> reg.h:1013:#define AR_PCIE_MSI 0x4094
> reg.h:1014:#define AR_PCIE_MSI_ENABLE 0x00000001
>
>
According to ath9k developers adding MSI support to the driver is not
trivial.
They've tried once, it didn't work and they gave up. Any chance I can use
mini-PCI-E slot without MSI ?
Thanks.
Felix.
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Benjamin Herrenschmidt @ 2009-12-17 7:07 UTC (permalink / raw)
To: Michael Neuling; +Cc: Mahesh Salgaonkar, Masami Hiramatsu, linuxppc-dev
In-Reply-To: <13884.1261016575@neuling.org>
On Thu, 2009-12-17 at 13:22 +1100, Michael Neuling wrote:
> > + * The @offset is the offset of the register in struct pt_regs.
> > + * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
> > + */
> > +static inline unsigned long regs_get_register(struct pt_regs *regs,
> > + unsigned int offset)
>
> Please put only function definitions in the .h file. The rest of this
> should be in .c
Not really in that case actually. There are just simple accessors, we
traditionally have them in .h files so they get fully inlined when
used.
I'll have a look at the rest of the patch asap, hopefully tomorrow.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] mpic: fix problem that affinity is not updated
From: Li Yang @ 2009-12-17 6:18 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Jiajun Wu
Since commit 57b150cce8e004ddd36330490a68bfb59b7271e9, desc->affinity
of an irq is changed after calling desc->chip->set_affinity.
Therefore we need to fix the irq_choose_cpu() not to depend on the
desc->affinity for new mask.
Signed-off-by: Jiajun Wu <b06378@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/sysdev/mpic.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 30c44e6..54ef5cd 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -567,12 +567,11 @@ static void __init mpic_scan_ht_pics(struct mpic *mpic)
#endif /* CONFIG_MPIC_U3_HT_IRQS */
#ifdef CONFIG_SMP
-static int irq_choose_cpu(unsigned int virt_irq)
+static int irq_choose_cpu(const cpumask_t *cpumask)
{
- cpumask_t mask;
+ cpumask_t mask = *cpumask;
int cpuid;
- cpumask_copy(&mask, irq_desc[virt_irq].affinity);
if (cpus_equal(mask, CPU_MASK_ALL)) {
static int irq_rover;
static DEFINE_SPINLOCK(irq_rover_lock);
@@ -607,7 +606,7 @@ static int irq_choose_cpu(unsigned int virt_irq)
return get_hard_smp_processor_id(cpuid);
}
#else
-static int irq_choose_cpu(unsigned int virt_irq)
+static int irq_choose_cpu(const cpumask_t *cpumask)
{
return hard_smp_processor_id();
}
@@ -816,7 +815,7 @@ int mpic_set_affinity(unsigned int irq, const struct cpumask *cpumask)
unsigned int src = mpic_irq_to_hw(irq);
if (mpic->flags & MPIC_SINGLE_DEST_CPU) {
- int cpuid = irq_choose_cpu(irq);
+ int cpuid = irq_choose_cpu(cpumask);
mpic_irq_write(src, MPIC_INFO(IRQ_DESTINATION), 1 << cpuid);
} else {
--
1.6.6-rc1.GIT
^ permalink raw reply related
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Masami Hiramatsu @ 2009-12-17 5:38 UTC (permalink / raw)
To: Michael Neuling; +Cc: Mahesh Salgaonkar, linuxppc-dev
In-Reply-To: <13884.1261016575@neuling.org>
Hi Michael,
Michael Neuling wrote:
>> +
>> +static const struct pt_regs_offset regoffset_table[] = {
>> + REG_OFFSET_NAME(gpr[0]),
>> + REG_OFFSET_NAME(gpr[1]),
>> + REG_OFFSET_NAME(gpr[2]),
>> + REG_OFFSET_NAME(gpr[3]),
>> + REG_OFFSET_NAME(gpr[4]),
>> + REG_OFFSET_NAME(gpr[5]),
>> + REG_OFFSET_NAME(gpr[6]),
>> + REG_OFFSET_NAME(gpr[7]),
>> + REG_OFFSET_NAME(gpr[8]),
>> + REG_OFFSET_NAME(gpr[9]),
>> + REG_OFFSET_NAME(gpr[10]),
>> + REG_OFFSET_NAME(gpr[11]),
>> + REG_OFFSET_NAME(gpr[12]),
>> + REG_OFFSET_NAME(gpr[13]),
>> + REG_OFFSET_NAME(gpr[14]),
>> + REG_OFFSET_NAME(gpr[15]),
>> + REG_OFFSET_NAME(gpr[16]),
>> + REG_OFFSET_NAME(gpr[17]),
>> + REG_OFFSET_NAME(gpr[18]),
>> + REG_OFFSET_NAME(gpr[19]),
>> + REG_OFFSET_NAME(gpr[20]),
>> + REG_OFFSET_NAME(gpr[21]),
>> + REG_OFFSET_NAME(gpr[22]),
>> + REG_OFFSET_NAME(gpr[23]),
>> + REG_OFFSET_NAME(gpr[24]),
>> + REG_OFFSET_NAME(gpr[25]),
>> + REG_OFFSET_NAME(gpr[26]),
>> + REG_OFFSET_NAME(gpr[27]),
>> + REG_OFFSET_NAME(gpr[28]),
>> + REG_OFFSET_NAME(gpr[29]),
>> + REG_OFFSET_NAME(gpr[30]),
>> + REG_OFFSET_NAME(gpr[31]),
>> + REG_OFFSET_NAME(nip),
>> + REG_OFFSET_NAME(msr),
>> + REG_OFFSET_NAME(orig_gpr3),
>> + REG_OFFSET_NAME(ctr),
>> + REG_OFFSET_NAME(link),
>> + REG_OFFSET_NAME(xer),
>> + REG_OFFSET_NAME(ccr),
>> +#ifdef CONFIG_PPC64
>> + REG_OFFSET_NAME(softe),
>> +#else
>> + REG_OFFSET_NAME(mq),
>> +#endif
>> + REG_OFFSET_NAME(trap),
>> + REG_OFFSET_NAME(dar),
>> + REG_OFFSET_NAME(dsisr),
>> + REG_OFFSET_NAME(result),
>> + REG_OFFSET_END,
>
> Do we need to add something for FP and VMX registers here?
Hmm, are FP and VMX registers actually used inside kernel on PPC?
Actually, the main purpose of this code is to provide accessing method
of in-kernel pt_regs fields (registers used in kernel) by name.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
^ permalink raw reply
* Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
From: Jesse Barnes @ 2009-12-17 2:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linux-pci, blofeldus, linuxppc-dev,
linux-kernel@vger.kernel.org
In-Reply-To: <1260341533.16132.20.camel@pasglop>
On Wed, 09 Dec 2009 17:52:13 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> The cardbus code creates PCI devices without ever going through the
> necessary fixup bits and pieces that normal PCI devices go through.
>
> There's in fact a commented out call to pcibios_fixup_bus() in there,
> it's commented because ... it doesn't work.
>
> I could make pcibios_fixup_bus() do the right thing on powerpc easily
> but I felt it cleaner instead to provide a specific hook
> pci_fixup_cardbus for which a weak empty implementation is provided
> by the PCI core.
>
> This fixes cardbus on powerbooks and probably all other PowerPC
> platforms which was broken completely for ever on some platforms and
> since 2.6.31 on others such as PowerBooks when we made the DMA ops
> mandatory (since those are setup by the fixups).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Ah the link failure was my fault. I had fixed up the conflict
incorrectly. It's applied now.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer
From: Michael Neuling @ 2009-12-17 2:22 UTC (permalink / raw)
To: Mahesh Salgaonkar; +Cc: linuxppc-dev, Masami Hiramatsu
In-Reply-To: <20091216043933.GA9328@in.ibm.com>
In message <20091216043933.GA9328@in.ibm.com> you wrote:
> This patch ports the kprobe-based event tracer to powerpc. This patch
> is based in x86 port. This brings powerpc on par with x86.
>
> Port the following API's to ppc for accessing registers and stack entries
> from pt_regs.
>
> - regs_query_register_offset(const char *name)
> Query the offset of "name" register.
>
> - regs_query_register_name(unsigned int offset)
> Query the name of register by its offset.
>
> - regs_get_register(struct pt_regs *regs, unsigned int offset)
> Get the value of a register by its offset.
>
> - regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
> Check the address is in the kernel stack.
>
> - regs_get_kernel_stack_nth(struct pt_regs *reg, unsigned int nth)
> Get Nth entry of the kernel stack. (N >= 0)
>
> - regs_get_argument_nth(struct pt_regs *reg, unsigned int nth)
> Get Nth argument at function call. (N >= 0)
>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> Acked-by: Masami Hiramatsu <mhiramat@redhat.com>
> ---
> arch/powerpc/include/asm/ptrace.h | 64 +++++++++++++++++
> arch/powerpc/kernel/ptrace.c | 141 +++++++++++++++++++++++++++++++++++
+++
> kernel/trace/Kconfig | 2
> 3 files changed, 206 insertions(+), 1 deletion(-)
>
> Index: linux-2.6-tip/arch/powerpc/include/asm/ptrace.h
> ===================================================================
> --- linux-2.6-tip.orig/arch/powerpc/include/asm/ptrace.h
> +++ linux-2.6-tip/arch/powerpc/include/asm/ptrace.h
> @@ -83,6 +83,7 @@ struct pt_regs {
>
> #define instruction_pointer(regs) ((regs)->nip)
> #define user_stack_pointer(regs) ((regs)->gpr[1])
> +#define kernel_stack_pointer(regs) ((regs)->gpr[1])
> #define regs_return_value(regs) ((regs)->gpr[3])
>
> #ifdef CONFIG_SMP
> @@ -131,6 +132,69 @@ do {
\
> } while (0)
> #endif /* __powerpc64__ */
>
> +/* Query offset/name of register from its name/offset */
> +#include <linux/stddef.h>
> +#include <linux/thread_info.h>
Includes should be at the start of the file
> +extern int regs_query_register_offset(const char *name);
> +extern const char *regs_query_register_name(unsigned int offset);
> +/* Get Nth argument at function call */
> +extern unsigned long regs_get_argument_nth(struct pt_regs *regs,
> + unsigned int n);
> +#define MAX_REG_OFFSET (offsetof(struct pt_regs, result))
> +
> +/**
> + * regs_get_register() - get register value from its offset
> + * @regs: pt_regs from which register value is gotten
> + * @offset: offset number of the register.
> + *
> + * regs_get_register returns the value of a register whose offset from @regs
.
> + * The @offset is the offset of the register in struct pt_regs.
> + * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
> + */
> +static inline unsigned long regs_get_register(struct pt_regs *regs,
> + unsigned int offset)
Please put only function definitions in the .h file. The rest of this
should be in .c
> +{
> + if (unlikely(offset > MAX_REG_OFFSET))
> + return 0;
> + return *(unsigned long *)((unsigned long)regs + offset);
> +}
> +
> +/**
> + * regs_within_kernel_stack() - check the address in the stack
> + * @regs: pt_regs which contains kernel stack pointer.
> + * @addr: address which is checked.
> + *
> + * regs_within_kernel_stack() checks @addr is within the kernel stack page(s
).
> + * If @addr is within the kernel stack, it returns true. If not, returns fal
se.
> + */
> +
> +static inline bool regs_within_kernel_stack(struct pt_regs *regs,
> + unsigned long addr)
> +{
> + return ((addr & ~(THREAD_SIZE - 1)) ==
> + (kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1)));
> +}
> +
> +/**
> + * regs_get_kernel_stack_nth() - get Nth entry of the stack
> + * @regs: pt_regs which contains kernel stack pointer.
> + * @n: stack entry number.
> + *
> + * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
> + * is specified by @regs. If the @n th entry is NOT in the kernel stack,
> + * this returns 0.
> + */
> +static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
> + unsigned int n)
> +{
> + unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
> + addr += n;
> + if (regs_within_kernel_stack(regs, (unsigned long)addr))
> + return *addr;
> + else
> + return 0;
> +}
> +
> /*
> * These are defined as per linux/ptrace.h, which see.
> */
> Index: linux-2.6-tip/arch/powerpc/kernel/ptrace.c
> ===================================================================
> --- linux-2.6-tip.orig/arch/powerpc/kernel/ptrace.c
> +++ linux-2.6-tip/arch/powerpc/kernel/ptrace.c
> @@ -39,6 +39,147 @@
> #include <asm/system.h>
>
> /*
> + * The parameter save area on the stack is used to store arguments being pas
sed
> + * to callee function and is located at fixed offset from stack pointer.
> + */
> +#ifdef CONFIG_PPC32
> +#define PARAMETER_SAVE_AREA_OFFSET 24 /* bytes */
> +#else /* CONFIG_PPC32 */
> +#define PARAMETER_SAVE_AREA_OFFSET 48 /* bytes */
> +#endif
> +
> +struct pt_regs_offset {
> + const char *name;
> + int offset;
> +};
> +
> +#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r
)}
> +#define REG_OFFSET_END {.name = NULL, .offset = 0}
> +
> +static const struct pt_regs_offset regoffset_table[] = {
> + REG_OFFSET_NAME(gpr[0]),
> + REG_OFFSET_NAME(gpr[1]),
> + REG_OFFSET_NAME(gpr[2]),
> + REG_OFFSET_NAME(gpr[3]),
> + REG_OFFSET_NAME(gpr[4]),
> + REG_OFFSET_NAME(gpr[5]),
> + REG_OFFSET_NAME(gpr[6]),
> + REG_OFFSET_NAME(gpr[7]),
> + REG_OFFSET_NAME(gpr[8]),
> + REG_OFFSET_NAME(gpr[9]),
> + REG_OFFSET_NAME(gpr[10]),
> + REG_OFFSET_NAME(gpr[11]),
> + REG_OFFSET_NAME(gpr[12]),
> + REG_OFFSET_NAME(gpr[13]),
> + REG_OFFSET_NAME(gpr[14]),
> + REG_OFFSET_NAME(gpr[15]),
> + REG_OFFSET_NAME(gpr[16]),
> + REG_OFFSET_NAME(gpr[17]),
> + REG_OFFSET_NAME(gpr[18]),
> + REG_OFFSET_NAME(gpr[19]),
> + REG_OFFSET_NAME(gpr[20]),
> + REG_OFFSET_NAME(gpr[21]),
> + REG_OFFSET_NAME(gpr[22]),
> + REG_OFFSET_NAME(gpr[23]),
> + REG_OFFSET_NAME(gpr[24]),
> + REG_OFFSET_NAME(gpr[25]),
> + REG_OFFSET_NAME(gpr[26]),
> + REG_OFFSET_NAME(gpr[27]),
> + REG_OFFSET_NAME(gpr[28]),
> + REG_OFFSET_NAME(gpr[29]),
> + REG_OFFSET_NAME(gpr[30]),
> + REG_OFFSET_NAME(gpr[31]),
> + REG_OFFSET_NAME(nip),
> + REG_OFFSET_NAME(msr),
> + REG_OFFSET_NAME(orig_gpr3),
> + REG_OFFSET_NAME(ctr),
> + REG_OFFSET_NAME(link),
> + REG_OFFSET_NAME(xer),
> + REG_OFFSET_NAME(ccr),
> +#ifdef CONFIG_PPC64
> + REG_OFFSET_NAME(softe),
> +#else
> + REG_OFFSET_NAME(mq),
> +#endif
> + REG_OFFSET_NAME(trap),
> + REG_OFFSET_NAME(dar),
> + REG_OFFSET_NAME(dsisr),
> + REG_OFFSET_NAME(result),
> + REG_OFFSET_END,
Do we need to add something for FP and VMX registers here?
> +};
> +
> +/**
> + * regs_query_register_offset() - query register offset from its name
> + * @name: the name of a register
> + *
> + * regs_query_register_offset() returns the offset of a register in struct
> + * pt_regs from its name. If the name is invalid, this returns -EINVAL;
> + */
> +int regs_query_register_offset(const char *name)
> +{
> + const struct pt_regs_offset *roff;
> + for (roff = regoffset_table; roff->name != NULL; roff++)
> + if (!strcmp(roff->name, name))
> + return roff->offset;
> + return -EINVAL;
> +}
> +
> +/**
> + * regs_query_register_name() - query register name from its offset
> + * @offset: the offset of a register in struct pt_regs.
> + *
> + * regs_query_register_name() returns the name of a register from its
> + * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
> + */
> +const char *regs_query_register_name(unsigned int offset)
> +{
> + const struct pt_regs_offset *roff;
> + for (roff = regoffset_table; roff->name != NULL; roff++)
> + if (roff->offset == offset)
> + return roff->name;
> + return NULL;
> +}
> +
> +static const int arg_offs_table[] = {
> + [0] = offsetof(struct pt_regs, gpr[3]),
> + [1] = offsetof(struct pt_regs, gpr[4]),
> + [2] = offsetof(struct pt_regs, gpr[5]),
> + [3] = offsetof(struct pt_regs, gpr[6]),
> + [4] = offsetof(struct pt_regs, gpr[7]),
> + [5] = offsetof(struct pt_regs, gpr[8]),
> + [6] = offsetof(struct pt_regs, gpr[9]),
> + [7] = offsetof(struct pt_regs, gpr[10])
> +};
> +
> +/**
> + * regs_get_argument_nth() - get Nth argument at function call
> + * @regs: pt_regs which contains registers at function entry.
> + * @n: argument number.
> + *
> + * regs_get_argument_nth() returns @n th argument of a function call.
> + * Since usually the kernel stack will be changed right after function entry
,
> + * you must use this at function entry. If the @n th entry is NOT in the
> + * kernel stack or pt_regs, this returns 0.
> + */
> +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned int n)
> +{
> + if (n < ARRAY_SIZE(arg_offs_table))
> + return *(unsigned long *)((char *)regs + arg_offs_table[n]);
> + else {
> + /*
> + * If more arguments are passed that can be stored in
> + * registers, the remaining arguments are stored in the
> + * parameter save area located at fixed offset from stack
> + * pointer.
> + * Following the PowerPC ABI, the first few arguments are
> + * actually passed in registers (r3-r10), with equivalent space
> + * left unused in the parameter save area.
> + */
> + n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
> + return regs_get_kernel_stack_nth(regs, n);
How do we handle FP args?
> + }
> +}
> +/*
> * does not yet catch signals sent when the child dies.
> * in exit.c or in signal.c.
> */
> Index: linux-2.6-tip/kernel/trace/Kconfig
> ===================================================================
> --- linux-2.6-tip.orig/kernel/trace/Kconfig
> +++ linux-2.6-tip/kernel/trace/Kconfig
> @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
>
> config KPROBE_EVENT
> depends on KPROBES
> - depends on X86
> + depends on X86 || PPC
> bool "Enable kprobes-based dynamic events"
> select TRACING
> default y
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Fix stupid bug in subpge protection handling
From: David Gibson @ 2009-12-17 0:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, linux-kernel
Cc: Thomas Q Klein, . Jan-Bernd Themann
Commit d28513bc7f675d28b479db666d572e078ecf182d ("Fix bug in pagetable
cache cleanup with CONFIG_PPC_SUBPAGE_PROT"), itself a fix for
breakage caused by an earlier clean up patch of mine, contains a
stupid bug. I changed the parameters of the subpage_protection()
function, but failed to update one of the callers.
This patch fixes it, and replaces a void * with a typed pointer so
that the compiler will warn on such an error in future.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Index: working-2.6/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/hash_utils_64.c 2009-12-16 11:43:51.357324268 +1100
+++ working-2.6/arch/powerpc/mm/hash_utils_64.c 2009-12-16 11:44:35.473351990 +1100
@@ -879,7 +879,7 @@ static inline int subpage_protection(str
*/
int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
{
- void *pgdir;
+ pgd_t *pgdir;
unsigned long vsid;
struct mm_struct *mm;
pte_t *ptep;
@@ -1025,7 +1025,7 @@ int hash_page(unsigned long ea, unsigned
else
#endif /* CONFIG_PPC_HAS_HASH_64K */
{
- int spp = subpage_protection(pgdir, ea);
+ int spp = subpage_protection(mm, ea);
if (access & spp)
rc = -2;
else
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
From: Benjamin Herrenschmidt @ 2009-12-16 22:54 UTC (permalink / raw)
To: Jesse Barnes
Cc: Olof Johansson, linux-pci, blofeldus, linuxppc-dev,
linux-kernel@vger.kernel.org
In-Reply-To: <20091216140128.16afbeb7@jbarnes-piketon>
On Wed, 2009-12-16 at 14:01 -0800, Jesse Barnes wrote:
> > Olof, once that's in you should be able to remove the hack you have in
> > the PA-Semi code to work around this.
> >
>
> Oops, looks like this fails for the modular case? I get an unresolved
> symbol error when building this with my default config...
>
> Care to resend with the fix against my for-linus branch?
Care to send a log ? I fail to see where the problem is since the patch
has:
--- linux-work.orig/drivers/pci/pci.c 2009-12-09 17:33:24.000000000 +1100
+++ linux-work/drivers/pci/pci.c 2009-12-09 17:34:16.000000000 +1100
@@ -2723,6 +2723,11 @@ int __attribute__ ((weak)) pci_ext_cfg_a
return 1;
}
+void __weak pci_fixup_cardbus(struct pci_bus *bus)
+{
+}
+EXPORT_SYMBOL(pci_fixup_cardbus);
Or is that broken in some way ?
I'm starting to regret trying to use weak stuff :-) I may turn it into a good
old:
#ifndef pcibios_fixup_cardbus
static inline void pcibios_fixup_cardbus(struct pci_bus *bus) { }
#define pcibios_fixup_cardbus
#endif
In a header and have ppc define it.
(And call it pcibios_ instead of pci_ which matches better what other arch
fixups are called :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Dan Williams @ 2009-12-16 22:47 UTC (permalink / raw)
To: Kumar Gala
Cc: herbert@gondor.apana.org.au, B04825@freescale.com,
linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
linuxppc-dev@ozlabs.org, Vishnu Suresh,
linux-crypto@vger.kernel.org, Dipen Dudhat, Maneesh Gupta,
R58472@freescale.com
In-Reply-To: <2868C8CF-584B-4FA7-9C3B-2FACEF77527E@kernel.crashing.org>
Kumar Gala wrote:
>>> Changes with respect to v1 as per comments received
>>> o. Rebased to linux-next as of 20091216
>>> o. The selection is based exclusive of fsldma
>>> o. Intoduced a new Kernel Configuration variable
>>> *. This enables selecting the Cryptographic functionality
>>> of Talitos along with fsldma.
>>> *. Disables the XOR parity calculation offload, if fsldma enabled
>>> either as kernel in-built or as a module
>>> *. Once the inter-operability with fsldma is resolved, this option
>>> can be removed
>> wait, why can't the interoperability bug be fixed in the first place?
>
> I agree w/Kim. We need to better understand what the bug is and how to reproduce it so we can get to the root cause.
>
> Paper taping over it by disabling fsldma is not the right solution.
Hopefully this prompts fsldma authors to get involved because the
interoperability issue has been out there without comment*, just
band-aids, since October.
--
Dan
* well one comment from Ira saying the interrupt functionality worked
for him.
^ permalink raw reply
* Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Kumar Gala @ 2009-12-16 22:38 UTC (permalink / raw)
To: Kim Phillips
Cc: herbert, B04825, linux-kernel, linux-raid, linuxppc-dev,
Vishnu Suresh, linux-crypto, Dipen Dudhat, dan.j.williams,
Maneesh Gupta, R58472
In-Reply-To: <20091216164144.daff5468.kim.phillips@freescale.com>
On Dec 16, 2009, at 4:41 PM, Kim Phillips wrote:
> On Wed, 16 Dec 2009 21:04:58 +0530
> Vishnu Suresh <Vishnu@freescale.com> wrote:
>=20
>> Expose Talitos's XOR functionality to be used for
>> RAID Parity calculation via the Async_tx layer.
>>=20
>> Known Issue:
>> When used with fsldma, random crashes are observed
>> on some platforms. Hence, inter-operability with fsldma
>> is currently disabled
>>=20
>> Thanks to Surender Kumar and Lee Nipper for their help in
>> realising this driver
>>=20
>> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
>> Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
>> Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
>> Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
>> ---
>> Changes with respect to v1 as per comments received
>> o. Rebased to linux-next as of 20091216
>> o. The selection is based exclusive of fsldma
>> o. Intoduced a new Kernel Configuration variable
>> *. This enables selecting the Cryptographic functionality
>> of Talitos along with fsldma.
>> *. Disables the XOR parity calculation offload, if fsldma enabled
>> either as kernel in-built or as a module
>> *. Once the inter-operability with fsldma is resolved, this option
>> can be removed
>=20
> wait, why can't the interoperability bug be fixed in the first place?
I agree w/Kim. We need to better understand what the bug is and how to =
reproduce it so we can get to the root cause.
Paper taping over it by disabling fsldma is not the right solution.
- k=
^ permalink raw reply
* Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Kim Phillips @ 2009-12-16 22:41 UTC (permalink / raw)
To: Vishnu Suresh
Cc: herbert, B04825, linux-kernel, linux-raid, linuxppc-dev,
linux-crypto, Dipen Dudhat, dan.j.williams, Maneesh Gupta, R58472
In-Reply-To: <1260977698-4076-1-git-send-email-Vishnu@freescale.com>
On Wed, 16 Dec 2009 21:04:58 +0530
Vishnu Suresh <Vishnu@freescale.com> wrote:
> Expose Talitos's XOR functionality to be used for
> RAID Parity calculation via the Async_tx layer.
>
> Known Issue:
> When used with fsldma, random crashes are observed
> on some platforms. Hence, inter-operability with fsldma
> is currently disabled
>
> Thanks to Surender Kumar and Lee Nipper for their help in
> realising this driver
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
> Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
> Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> ---
> Changes with respect to v1 as per comments received
> o. Rebased to linux-next as of 20091216
> o. The selection is based exclusive of fsldma
> o. Intoduced a new Kernel Configuration variable
> *. This enables selecting the Cryptographic functionality
> of Talitos along with fsldma.
> *. Disables the XOR parity calculation offload, if fsldma enabled
> either as kernel in-built or as a module
> *. Once the inter-operability with fsldma is resolved, this option
> can be removed
wait, why can't the interoperability bug be fixed in the first place?
Kim
^ permalink raw reply
* Re: AltiVec in the kernel
From: Sebastian Andrzej Siewior @ 2009-12-16 22:11 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Simon Richter, linuxppc-dev
In-Reply-To: <200912111649.25617.arnd@arndb.de>
* Arnd Bergmann | 2009-12-11 16:49:25 [+0100]:
>On Friday 11 December 2009, Simon Richter wrote:
>> Hi,
>>
>> since there has been a thread on allowing the use of a coprocessor in
>> the kernel already: I am wondering if it'd make sense to use AltiVec for
>> AES in dm-crypt, and how difficult it would be to implement that.
>>
>> I'm using a PegasosII which has a G4 running at 1 GHz; I get around 3
>> MB/s throughput when accessing harddisks. I think that could be
>> improved.
>>
>> If I understand correctly, the actual encryption work runs in a kernel
>> thread, which is scheduled normally, so it ought to be possible to
>> enable AltiVec for that thread; am I missing something here?
dm-crypt is async these days so the patches Arnd mentioned could be
used actually :) I've never tested them with dm-crypt but it should
work. Back then I had around 20MiB/sec encryption and around 15 MiB/sec
for decryption on 4KiB page on a PS3 [0]. This was pure testing, no
subsystem was involved. dm-crypt will feed multiple 512 byte requests.
And according [1] 512 bytes are aren't slow :) However [2] says that
that AltiVec was always slower than the generic implementation. Maybe
PS3's AltiVec unit was slower than the average one because everyone was
focuesed on the SPUs. Maybe not and you get similar results.
>Sebastian Siewior has implemented this some time ago:
>
>http://old.nabble.com/-RFC-0-3--Experiments-with-AES-AltiVec,-part-2-tc10034255.html
>
>You can try the old patches on your machine to see if they are any good
>there.
Ah you remember :)
[0] http://diploma-thesis.siewior.net/html/diplomarbeitch4.html#x12-46002r2
[1] http://diploma-thesis.siewior.net/html/diplomarbeitch4.html#x12-46004r4
[2] http://diploma-thesis.siewior.net/html/diplomarbeitch4.html#x12-47017r5
>
> Arnd <><
Sebastian
^ permalink raw reply
* Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
From: Jesse Barnes @ 2009-12-16 22:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linux-pci, blofeldus, linuxppc-dev,
linux-kernel@vger.kernel.org
In-Reply-To: <1260341533.16132.20.camel@pasglop>
On Wed, 09 Dec 2009 17:52:13 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> The cardbus code creates PCI devices without ever going through the
> necessary fixup bits and pieces that normal PCI devices go through.
>
> There's in fact a commented out call to pcibios_fixup_bus() in there,
> it's commented because ... it doesn't work.
>
> I could make pcibios_fixup_bus() do the right thing on powerpc easily
> but I felt it cleaner instead to provide a specific hook
> pci_fixup_cardbus for which a weak empty implementation is provided
> by the PCI core.
>
> This fixes cardbus on powerbooks and probably all other PowerPC
> platforms which was broken completely for ever on some platforms and
> since 2.6.31 on others such as PowerBooks when we made the DMA ops
> mandatory (since those are setup by the fixups).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Note: In the long run we might want to streamline the hooks for fixing
> up new devices vs. new busses and make some stuff common between
> cardbus and PCI hotplug which is actually a mess.
>
> This is a quick fix that makes it work again in the meantime, and that
> I would like to see in 2.6.31 and 2.6.32 stable at least.
>
> Another option if you prefer is I can make my pcibios_fixup_bus() do
> the right thing in all cases I believe (by testing bus->is_added to
> skip stuff that must not be done twice) and we can remove the comment
> and stick the call in #ifdef CONFIG_PPC but I felt that solution was
> a tad cleaner.
>
> Olof, once that's in you should be able to remove the hack you have in
> the PA-Semi code to work around this.
>
Oops, looks like this fails for the modular case? I get an unresolved
symbol error when building this with my default config...
Care to resend with the fix against my for-linus branch?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
From: Jesse Barnes @ 2009-12-16 19:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linux-pci, blofeldus, linuxppc-dev,
linux-kernel@vger.kernel.org
In-Reply-To: <1260341533.16132.20.camel@pasglop>
On Wed, 09 Dec 2009 17:52:13 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> The cardbus code creates PCI devices without ever going through the
> necessary fixup bits and pieces that normal PCI devices go through.
>
> There's in fact a commented out call to pcibios_fixup_bus() in there,
> it's commented because ... it doesn't work.
>
> I could make pcibios_fixup_bus() do the right thing on powerpc easily
> but I felt it cleaner instead to provide a specific hook
> pci_fixup_cardbus for which a weak empty implementation is provided
> by the PCI core.
>
> This fixes cardbus on powerbooks and probably all other PowerPC
> platforms which was broken completely for ever on some platforms and
> since 2.6.31 on others such as PowerBooks when we made the DMA ops
> mandatory (since those are setup by the fixups).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Applied, thanks. Had to fix up a conflict since someone had "helpfully"
changed the comment from a // to a /* .. */ in cardbus.c.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH] powerpc: fix cpu name in show-cpuinfo
From: Michael Wolf @ 2009-12-16 17:53 UTC (permalink / raw)
To: linuxppc-dev
When looking at /proc/cpuinfo the cpuname will be 'unknown"
if the pvr mask is 0. This is the case for the kernel running
on new or unknown hardware. However the cpuname is always specified
so use the name regardless of the pvr mask.
Signed-off-by: Mike Wolf <mjw@us.ibm.com>
---
--- mainline.orig/arch/powerpc/kernel/setup-common.c 2009-12-15
11:33:36.000000000 -0600
+++ mainline/arch/powerpc/kernel/setup-common.c 2009-12-16
11:26:26.000000000 -0600
@@ -219,7 +219,7 @@
seq_printf(m, "processor\t: %lu\n", cpu_id);
seq_printf(m, "cpu\t\t: ");
- if (cur_cpu_spec->pvr_mask)
+ if (cur_cpu_spec->cpu_name)
seq_printf(m, "%s", cur_cpu_spec->cpu_name);
else
seq_printf(m, "unknown (%08x)", pvr);
^ permalink raw reply
* [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Vishnu Suresh @ 2009-12-16 15:34 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-raid, dan.j.williams,
linux-crypto, herbert
Cc: R58472, B04825, Vishnu Suresh, Dipen Dudhat, Maneesh Gupta
Expose Talitos's XOR functionality to be used for
RAID Parity calculation via the Async_tx layer.
Known Issue:
When used with fsldma, random crashes are observed
on some platforms. Hence, inter-operability with fsldma
is currently disabled
Thanks to Surender Kumar and Lee Nipper for their help in
realising this driver
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
---
Changes with respect to v1 as per comments received
o. Rebased to linux-next as of 20091216
o. The selection is based exclusive of fsldma
o. Intoduced a new Kernel Configuration variable
*. This enables selecting the Cryptographic functionality
of Talitos along with fsldma.
*. Disables the XOR parity calculation offload, if fsldma enabled
either as kernel in-built or as a module
*. Once the inter-operability with fsldma is resolved, this option
can be removed
drivers/crypto/Kconfig | 9 +
drivers/crypto/talitos.c | 402 +++++++++++++++++++++++++++++++++++++++++++++-
drivers/crypto/talitos.h | 2 +
3 files changed, 412 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index b08403d..f8a6376 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -203,6 +203,15 @@ config CRYPTO_DEV_TALITOS
To compile this driver as a module, choose M here: the module
will be called talitos.
+config CRYPTO_DEV_TALITOS_RAIDXOR
+ bool "Talitos RAID5 XOR Calculation Offload"
+ select DMA_ENGINE
+ depends on CRYPTO_DEV_TALITOS
+ depends on FSL_DMA=n
+ help
+ Say 'Y' here to use the Freescale Security Engine (SEC) to
+ offload RAID XOR parity Calculation
+
config CRYPTO_DEV_IXP4XX
tristate "Driver for IXP4xx crypto hardware acceleration"
depends on ARCH_IXP4XX
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c47ffe8..e63b25a 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1,7 +1,7 @@
/*
* talitos - Freescale Integrated Security Engine (SEC) device driver
*
- * Copyright (c) 2008 Freescale Semiconductor, Inc.
+ * Copyright (c) 2008-2009 Freescale Semiconductor, Inc.
*
* Scatterlist Crypto API glue code copied from files with the following:
* Copyright (c) 2006-2007 Herbert Xu <herbert@gondor.apana.org.au>
@@ -37,6 +37,8 @@
#include <linux/io.h>
#include <linux/spinlock.h>
#include <linux/rtnetlink.h>
+#include <linux/dmaengine.h>
+#include <linux/raid/xor.h>
#include <crypto/algapi.h>
#include <crypto/aes.h>
@@ -140,6 +142,10 @@ struct talitos_private {
/* hwrng device */
struct hwrng rng;
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+ /* XOR Device */
+ struct dma_device dma_dev_common;
+#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
};
/* .features flag */
@@ -684,6 +690,375 @@ static void talitos_unregister_rng(struct device *dev)
hwrng_unregister(&priv->rng);
}
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+/*
+ * async_tx interface for XOR-capable SECs
+ *
+ * Dipen Dudhat <Dipen.Dudhat@freescale.com>
+ * Maneesh Gupta <Maneesh.Gupta@freescale.com>
+ * Vishnu Suresh <Vishnu@freescale.com>
+ */
+
+/**
+ * talitos_xor_chan - context management for the async_tx channel
+ * @completed_cookie: the last completed cookie
+ * @desc_lock: lock for tx queue
+ * @total_desc: number of descriptors allocated
+ * @submit_q: queue of submitted descriptors
+ * @pending_q: queue of pending descriptors
+ * @in_progress_q: queue of descriptors in progress
+ * @free_desc: queue of unused descriptors
+ * @dev: talitos device implementing this channel
+ * @common: the corresponding xor channel in async_tx
+ */
+struct talitos_xor_chan {
+ dma_cookie_t completed_cookie;
+ spinlock_t desc_lock;
+ unsigned int total_desc;
+ struct list_head submit_q;
+ struct list_head pending_q;
+ struct list_head in_progress_q;
+ struct list_head free_desc;
+ struct device *dev;
+ struct dma_chan common;
+};
+
+/**
+ * talitos_xor_desc - software xor descriptor
+ * @async_tx: the referring async_tx descriptor
+ * @node:
+ * @hwdesc: h/w descriptor
+ */
+struct talitos_xor_desc {
+ struct dma_async_tx_descriptor async_tx;
+ struct list_head tx_list;
+ struct list_head node;
+ struct talitos_desc hwdesc;
+};
+
+static enum dma_status talitos_is_tx_complete(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ dma_cookie_t *done,
+ dma_cookie_t *used)
+{
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t last_used;
+ dma_cookie_t last_complete;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ last_used = chan->cookie;
+ last_complete = xor_chan->completed_cookie;
+
+ if (done)
+ *done = last_complete;
+
+ if (used)
+ *used = last_used;
+
+ return dma_async_is_complete(cookie, last_complete, last_used);
+}
+
+static void talitos_release_xor(struct device *dev, struct talitos_desc *hwdesc,
+ void *context, int error)
+{
+ struct talitos_xor_desc *desc = context;
+ struct talitos_xor_chan *xor_chan;
+ dma_async_tx_callback callback;
+ void *callback_param;
+
+ if (unlikely(error)) {
+ dev_err(dev, "xor operation: talitos error %d\n", error);
+ BUG();
+ }
+
+ xor_chan = container_of(desc->async_tx.chan, struct talitos_xor_chan,
+ common);
+ spin_lock_bh(&xor_chan->desc_lock);
+ if (xor_chan->completed_cookie < desc->async_tx.cookie)
+ xor_chan->completed_cookie = desc->async_tx.cookie;
+
+ callback = desc->async_tx.callback;
+ callback_param = desc->async_tx.callback_param;
+ list_del(&desc->node);
+ list_add_tail(&desc->node, &xor_chan->free_desc);
+ spin_unlock_bh(&xor_chan->desc_lock);
+
+ if (callback)
+ callback(callback_param);
+
+ /* run dependent operations */
+ dma_run_dependencies(&desc->async_tx);
+}
+
+static void talitos_process_pending(struct talitos_xor_chan *xor_chan)
+{
+ struct talitos_xor_desc *desc, *_desc;
+
+ spin_lock_bh(&xor_chan->desc_lock);
+ list_for_each_entry_safe(desc, _desc, &xor_chan->pending_q, node) {
+ if (talitos_submit(xor_chan->dev, &desc->hwdesc,
+ talitos_release_xor, desc) != -EINPROGRESS)
+ break;
+
+ list_del(&desc->node);
+ list_add_tail(&desc->node, &xor_chan->in_progress_q);
+ }
+ spin_unlock_bh(&xor_chan->desc_lock);
+}
+
+/**
+ * talitos_issue_pending - move the descriptors in submit
+ * queue to pending queue and submit them for processing
+ * @chan: DMA channel
+ */
+static void talitos_issue_pending(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+ spin_lock_bh(&xor_chan->desc_lock);
+ list_splice_tail_init(&xor_chan->submit_q,
+ &xor_chan->pending_q);
+ spin_unlock_bh(&xor_chan->desc_lock);
+ talitos_process_pending(xor_chan);
+}
+
+static dma_cookie_t talitos_async_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+ struct talitos_xor_desc *desc;
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t cookie;
+
+ desc = container_of(tx, struct talitos_xor_desc, async_tx);
+ xor_chan = container_of(tx->chan, struct talitos_xor_chan, common);
+
+ cookie = xor_chan->common.cookie + 1;
+ if (cookie < 0)
+ cookie = 1;
+
+ desc->async_tx.cookie = cookie;
+ xor_chan->common.cookie = desc->async_tx.cookie;
+
+ list_splice_tail_init(&desc->tx_list,
+ &xor_chan->submit_q);
+
+ return cookie;
+}
+
+static struct talitos_xor_desc *talitos_xor_alloc_descriptor(
+ struct talitos_xor_chan *xor_chan, gfp_t flags)
+{
+ struct talitos_xor_desc *desc;
+
+ desc = kmalloc(sizeof(*desc), flags);
+ if (desc) {
+ xor_chan->total_desc++;
+ memset(desc, 0, sizeof(*desc));
+ dma_async_tx_descriptor_init(&desc->async_tx, &xor_chan->common);
+ desc->async_tx.tx_submit = talitos_async_tx_submit;
+ INIT_LIST_HEAD(&desc->node);
+ INIT_LIST_HEAD(&desc->tx_list);
+ }
+
+ return desc;
+}
+
+static void talitos_free_chan_resources(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *desc, *_desc;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ list_for_each_entry_safe(desc, _desc, &xor_chan->submit_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->pending_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->in_progress_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->free_desc, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ BUG_ON(unlikely(xor_chan->total_desc)); /* Some descriptor not freed? */
+}
+
+static int talitos_alloc_chan_resources(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *desc;
+ LIST_HEAD(tmp_list);
+ int i;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ if (!list_empty(&xor_chan->free_desc))
+ return xor_chan->total_desc;
+
+ /* 256 initial descriptors */
+ for (i = 0; i < 256; i++) {
+ desc = talitos_xor_alloc_descriptor(xor_chan, GFP_KERNEL);
+ if (!desc) {
+ dev_err(xor_chan->common.device->dev,
+ "Only %d initial descriptors\n", i);
+ break;
+ }
+ list_add_tail(&desc->node, &tmp_list);
+ }
+
+ if (!i)
+ return -ENOMEM;
+
+ /* At least one desc is allocated */
+ list_splice_init(&tmp_list, &xor_chan->free_desc);
+
+ return xor_chan->total_desc;
+}
+
+static struct dma_async_tx_descriptor * talitos_prep_dma_xor(
+ struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
+ unsigned int src_cnt, size_t len, unsigned long flags)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *new;
+ struct talitos_desc *desc;
+ int i, j;
+
+ BUG_ON(unlikely(len > TALITOS_MAX_DATA_LEN));
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ if (!list_empty(&xor_chan->free_desc)) {
+ new = container_of(xor_chan->free_desc.next,
+ struct talitos_xor_desc, node);
+ list_del(&new->node);
+ } else {
+ new = talitos_xor_alloc_descriptor(xor_chan, GFP_KERNEL);
+ }
+
+ if (!new) {
+ dev_err(xor_chan->common.device->dev,
+ "No free memory for XOR DMA descriptor\n");
+ return NULL;
+ }
+
+ desc = &new->hwdesc;
+ /* Set destination: Last pointer pair */
+ to_talitos_ptr(&desc->ptr[6], dest);
+ desc->ptr[6].len = cpu_to_be16(len);
+ desc->ptr[6].j_extent = 0;
+
+ /* Set Sources: End loading from second-last pointer pair */
+ for (i = 5, j = 0; (j < src_cnt) && (i > 0); i--, j++) {
+ to_talitos_ptr(&desc->ptr[i], src[j]);
+ desc->ptr[i].len = cpu_to_be16(len);
+ desc->ptr[i].j_extent = 0;
+ }
+
+ /*
+ * documentation states first 0 ptr/len combo marks end of sources
+ * yet device produces scatter boundary error unless all subsequent
+ * sources are zeroed out
+ */
+ for (; i >= 0; i--) {
+ to_talitos_ptr(&desc->ptr[i], 0);
+ desc->ptr[i].len = 0;
+ desc->ptr[i].j_extent = 0;
+ }
+
+ desc->hdr = DESC_HDR_SEL0_AESU | DESC_HDR_MODE0_AESU_XOR
+ | DESC_HDR_TYPE_RAID_XOR;
+
+ list_add_tail(&new->node, &new->tx_list);
+
+ new->async_tx.flags = flags;
+ new->async_tx.cookie = -EBUSY;
+
+ return &new->async_tx;
+}
+
+static void talitos_unregister_async_xor(struct device *dev)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ struct talitos_xor_chan *xor_chan;
+ struct dma_chan *chan;
+
+ if (priv->dma_dev_common.chancnt)
+ dma_async_device_unregister(&priv->dma_dev_common);
+
+ list_for_each_entry(chan, &priv->dma_dev_common.channels, device_node) {
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+ list_del(&chan->device_node);
+ priv->dma_dev_common.chancnt--;
+ kfree(xor_chan);
+ }
+}
+
+/**
+ * talitos_register_dma_async - Initialize the Freescale XOR ADMA device
+ * It is registered as a DMA device with the capability to perform
+ * XOR operation with the Async_tx layer.
+ * The various queues and channel resources are also allocated.
+ */
+static int talitos_register_async_tx(struct device *dev, int max_xor_srcs)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ struct dma_device *dma_dev = &priv->dma_dev_common;
+ struct talitos_xor_chan *xor_chan;
+ int err;
+
+ xor_chan = kzalloc(sizeof(struct talitos_xor_chan), GFP_KERNEL);
+ if (!xor_chan) {
+ dev_err(dev, "unable to allocate xor channel\n");
+ return -ENOMEM;
+ }
+
+ dma_dev->dev = dev;
+ dma_dev->device_alloc_chan_resources = talitos_alloc_chan_resources;
+ dma_dev->device_free_chan_resources = talitos_free_chan_resources;
+ dma_dev->device_prep_dma_xor = talitos_prep_dma_xor;
+ dma_dev->max_xor = max_xor_srcs;
+ dma_dev->device_is_tx_complete = talitos_is_tx_complete;
+ dma_dev->device_issue_pending = talitos_issue_pending;
+ INIT_LIST_HEAD(&dma_dev->channels);
+ dma_cap_set(DMA_XOR, dma_dev->cap_mask);
+
+ xor_chan->dev = dev;
+ xor_chan->common.device = dma_dev;
+ xor_chan->total_desc = 0;
+ INIT_LIST_HEAD(&xor_chan->submit_q);
+ INIT_LIST_HEAD(&xor_chan->pending_q);
+ INIT_LIST_HEAD(&xor_chan->in_progress_q);
+ INIT_LIST_HEAD(&xor_chan->free_desc);
+ spin_lock_init(&xor_chan->desc_lock);
+
+ list_add_tail(&xor_chan->common.device_node, &dma_dev->channels);
+ dma_dev->chancnt++;
+
+ err = dma_async_device_register(dma_dev);
+ if (err) {
+ dev_err(dev, "Unable to register XOR with Async_tx\n");
+ goto err_out;
+ }
+
+ return err;
+
+err_out:
+ talitos_unregister_async_xor(dev);
+ return err;
+}
+#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
/*
* crypto alg
*/
@@ -1768,6 +2143,10 @@ static int talitos_remove(struct of_device *ofdev)
tasklet_kill(&priv->done_task);
iounmap(priv->reg);
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+ if (priv->dma_dev_common.chancnt)
+ talitos_unregister_async_xor(dev);
+#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
dev_set_drvdata(dev, NULL);
@@ -1926,6 +2305,27 @@ static int talitos_probe(struct of_device *ofdev,
dev_info(dev, "hwrng\n");
}
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+ /*
+ * register with async_tx xor, if capable
+ * SEC 2.x support up to 3 RAID sources,
+ * SEC 3.x support up to 6
+ */
+ if (hw_supports(dev, DESC_HDR_SEL0_AESU | DESC_HDR_TYPE_RAID_XOR)) {
+ int max_xor_srcs = 3;
+ if (of_device_is_compatible(np, "fsl,sec3.0"))
+ max_xor_srcs = 6;
+
+ err = talitos_register_async_tx(dev, max_xor_srcs);
+ if (err) {
+ dev_err(dev, "failed to register async_tx xor: %d\n",
+ err);
+ goto err_out;
+ }
+ dev_info(dev, "max_xor_srcs %d\n", max_xor_srcs);
+ }
+#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
+
/* register crypto algorithms the device supports */
for (i = 0; i < ARRAY_SIZE(driver_algs); i++) {
if (hw_supports(dev, driver_algs[i].desc_hdr_template)) {
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index ff5a145..b6197bc 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -155,6 +155,7 @@
/* primary execution unit mode (MODE0) and derivatives */
#define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x00100000)
#define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x00200000)
+#define DESC_HDR_MODE0_AESU_XOR cpu_to_be32(0x0c600000)
#define DESC_HDR_MODE0_DEU_CBC cpu_to_be32(0x00400000)
#define DESC_HDR_MODE0_DEU_3DES cpu_to_be32(0x00200000)
#define DESC_HDR_MODE0_MDEU_INIT cpu_to_be32(0x01000000)
@@ -202,6 +203,7 @@
#define DESC_HDR_TYPE_IPSEC_ESP cpu_to_be32(1 << 3)
#define DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU cpu_to_be32(2 << 3)
#define DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU cpu_to_be32(4 << 3)
+#define DESC_HDR_TYPE_RAID_XOR cpu_to_be32(21 << 3)
/* link table extent field bits */
#define DESC_PTR_LNKTBL_JUMP 0x80
--
1.6.4.2
^ permalink raw reply related
* [PATCH v2 1/2] fsldma: Delete DMA_INTERRUPT capability
From: Vishnu Suresh @ 2009-12-16 15:34 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-raid, dan.j.williams
Cc: Vishnu Suresh, B04825, R58472
The DMA_INTERRUPT is a NULL transfer, triggering a
Programming Error. Though this Error is handled in
the driver with the fix given in "fsldma: Fix the DMA
halt when using DMA_INTERRUPT async_tx transfer."
<f79abb627f033c85a6088231f20c85bc4a9bd757>,
the RAID5 operation, which initiated the transaction
via Async_tx, hangs.
Hence, this patch removes the DMA_INTERRUPT capability
and the associated code from the driver.
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
---
Changes with respect to v1
o. Rebased to linux-next as of 20091216
drivers/dma/fsldma.c | 31 -------------------------------
1 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 296f9e7..272097a 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -449,35 +449,6 @@ static void fsl_dma_free_chan_resources(struct dma_chan *chan)
fsl_chan->desc_pool = NULL;
}
-static struct dma_async_tx_descriptor *
-fsl_dma_prep_interrupt(struct dma_chan *chan, unsigned long flags)
-{
- struct fsl_dma_chan *fsl_chan;
- struct fsl_desc_sw *new;
-
- if (!chan)
- return NULL;
-
- fsl_chan = to_fsl_chan(chan);
-
- new = fsl_dma_alloc_descriptor(fsl_chan);
- if (!new) {
- dev_err(fsl_chan->dev, "No free memory for link descriptor\n");
- return NULL;
- }
-
- new->async_tx.cookie = -EBUSY;
- new->async_tx.flags = flags;
-
- /* Insert the link descriptor to the LD ring */
- list_add_tail(&new->node, &new->tx_list);
-
- /* Set End-of-link to the last link descriptor of new list*/
- set_ld_eol(fsl_chan, new);
-
- return &new->async_tx;
-}
-
static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
struct dma_chan *chan, dma_addr_t dma_dest, dma_addr_t dma_src,
size_t len, unsigned long flags)
@@ -1200,11 +1171,9 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
- fdev->reg.start + 1);
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
- dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
- fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_is_tx_complete = fsl_dma_is_complete;
fdev->common.device_issue_pending = fsl_dma_memcpy_issue_pending;
--
1.6.4.2
^ 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