* Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Dan Williams @ 2009-12-17 17:44 UTC (permalink / raw)
To: Ira W. Snyder
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: <20091217170958.GE18271@ovro.caltech.edu>
Ira W. Snyder wrote:
> Yes, I have used the device_prep_dma_interrupt() functionality quite a
> while back. However, I found it to be pretty much useless.
The specific case it is needed for Talitos/raid is a channel switch
interrupt. The interrupt causes the cleanup operation to be run which
will kick off any pending dependent operations on the xor channel. In
the raid case we only have callbacks at the end of a chain, so we need
the interrupt to kick the engine in an operation chain like
xor->copy->xor->callback.
--
Dan
^ permalink raw reply
* Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Kumar Gala @ 2009-12-17 17:29 UTC (permalink / raw)
To: Ira W. Snyder
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, Dan Williams,
Maneesh Gupta, R58472@freescale.com
In-Reply-To: <20091217170958.GE18271@ovro.caltech.edu>
On Dec 17, 2009, at 11:09 AM, Ira W. Snyder wrote:
> On Wed, Dec 16, 2009 at 03:47:48PM -0700, Dan Williams wrote:
>> 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?
>>>=20
>>> 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.
>>>=20
>>> Paper taping over it by disabling fsldma is not the right solution.
>>=20
>> Hopefully this prompts fsldma authors to get involved because the=20
>> interoperability issue has been out there without comment*, just=20
>> band-aids, since October.
>>=20
>> --
>> Dan
>>=20
>> * well one comment from Ira saying the interrupt functionality worked=20=
>> for him.
>=20
> Yes, I have used the device_prep_dma_interrupt() functionality quite a
> while back. However, I found it to be pretty much useless. Any
> functionality I need is covered by adding a callback to the last DMA
> memcpy() operation. Since the operations happen in-order, I can be =
sure
> that the entire set of memcpy()s cas completed. I never needed the
> capability to generate an interrupt without a memcpy().
>=20
> I agree that the fsldma driver could use some love. There are places
> where I am still not confident in the locking. Perhaps I can find some
> time over Christmas to work on it, but I need someone with 85xx/86xx
> hardware to test the changes. I only have 83xx hardware.
I can test on 85xx/86xx if you work up some patches.
- k=
^ permalink raw reply
* Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Ira W. Snyder @ 2009-12-17 17:09 UTC (permalink / raw)
To: Dan Williams
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: <4B296394.9010709@intel.com>
On Wed, Dec 16, 2009 at 03:47:48PM -0700, Dan Williams wrote:
> 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.
Yes, I have used the device_prep_dma_interrupt() functionality quite a
while back. However, I found it to be pretty much useless. Any
functionality I need is covered by adding a callback to the last DMA
memcpy() operation. Since the operations happen in-order, I can be sure
that the entire set of memcpy()s cas completed. I never needed the
capability to generate an interrupt without a memcpy().
I agree that the fsldma driver could use some love. There are places
where I am still not confident in the locking. Perhaps I can find some
time over Christmas to work on it, but I need someone with 85xx/86xx
hardware to test the changes. I only have 83xx hardware.
Ira
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Kumar Gala @ 2009-12-17 17:01 UTC (permalink / raw)
To: Mahajan Vivek-B08308; +Cc: linuxppc-dev, Felix Radensky, Aggrwal Poonam-B10812
In-Reply-To: <0949C49693EF1A47A54B0F0113CDB4A60767F0@zin33exm23.fsl.freescale.net>
On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote:
>>=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 ?
>=20
> Correct
I'm confused. What's the issue with IRQ0 on the P2020RDB? Is it used =
for another purpose?
- k=
^ permalink raw reply
* Need advice on changing MPC5200B UART prescaler
From: Sylvain Lamontagne @ 2009-12-17 15:57 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]
Hi all,
I would like to be able to set a baud rate of 460800 for modem that we are
testing. With the actual prescaler of 32 and a IPB frequency of 84MHz
I got a 5.1% error (437500) vs a 0.9% error (456522) if I could use the
prescaler of 4. See MPC5200B user manual page 15-46 for the calculation
formula and page 15-12 for the CSR description.
Currently the code for the kernel we are using here, (2.6.29.2) seams not to
take a prescaler of 4 into account.
Line 249 of mpc52xx_uart.c
http://lxr.linux.no/linux+v2.6.29.2/drivers/serial/mpc52xx_uart.c#L249
/* Search for bus-frequency property in this node or a parent */
static unsigned long mpc52xx_getuartclk(void *p)
{
/*
* 5200 UARTs have a / 32 prescaler
* but the generic serial code assumes 16
* so return ipb freq / 2
*/
return mpc52xx_find_ipb_freq(p) / 2;
}
How could I make it use the prescaler of 4 without breaking anything that we
currently have working ?
I doubt that simply doing return mpc52xx_find_ipb_freq(p) / 4 would do the
trick ...
[-- Attachment #2: Type: text/html, Size: 1418 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC: const intspec pointers
From: Roman Fietze @ 2009-12-17 12:55 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40912151150o64f97533h1b736b4445301192@mail.gmail.com>
Hello Grant,
On Tuesday 15 December 2009 20:50:05 Grant Likely wrote:
> Yes, I'm using the driver in a couple of projects. It works for me
> for both RX and TX (although TX+DMA has been troublesome).
That's what I found out.
> The test driver on the other hand is pretty poor code. Don't expect
> much from it other than some hints. There's a reason I didn't merge
> that chunk.
I brought it up to speed before using it.
> Yes, please post the patches and cc: me. I'll review, test, and make
> comments.
I hope it's ok that I've copied them to my web space instead of
providing patches in a mail. The URL is:
http://www.fietze-home.de/telemotive/linux-2.6-telemotive-mpc.git
Branches:
benh-next-lpbfifo
the modified version of the LocalPlus platform driver
benh-next-localplus-test
your old test driver, now using the platform driver
Both branches are on top of the benh next branch.
I could only test the driver using fifo and bcom mode in read mode,
using your old test driver, because I currently do not yet have a
target with a writeable device on the LocalPlus. The test ran fine
using different transer sizes starting at 4 up to 128KiB.
I will now port our FPGA driver to use the platform driver, which can
deliver a very high load, and supports writing.
The biggest problem using DMA is the unpredictable order of arrival of
the two interrupts. They both depend on the appropriate load of the
system generating them. In the case of the BestComm a parallel load on
e.g. FEC or ATA can delay the bcom gen bd interrupt until it's task
gets scheduled again, which can take "some time" due its low BestComm
prio of 2. The second problem was, that the original driver does not
use the flush bit to avoid stale RX data.
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* 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
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