* Re: i2c_powermac: Kernel access of bad area
From: Benjamin Herrenschmidt @ 2010-01-29 21:34 UTC (permalink / raw)
To: Jean Delvare
Cc: Christian Kujau, linuxppc-dev, Michael Hanselmann, LKML,
Stelian Pop
In-Reply-To: <20100129091857.3b7228db@hyperion.delvare>
> Ben, what about applying this patch of mine, as Christian reported it
> fixed his oops?
Sure. I never quite know with i2c which ones you will apply directly and
which ones you want to go through my tree :-)
Hopefully they should still be referened on patchwork, I'll dig there
and pick them up.
Cheers,
Ben.
> > > However, the "Badness" remains when I try to modprobe i2c-powermac again:
> > >
> > > [ 442.148222] PowerMac i2c bus pmu 2 registered
> > > [ 442.148792] PowerMac i2c bus pmu 1 registered
> > > [ 442.149299] PowerMac i2c bus mac-io 0 registered
> > > [ 442.163573] adt746x: ADT7467 initializing
> > > [ 442.170072] adt746x: Lowering max temperatures from 73, 80, 109 to 67, 47, 67
> > > [ 442.176559] PowerMac i2c bus uni-n 1 registered
> > > [ 442.227115] sysfs: cannot create duplicate filename '/devices/ams'
> > > [ 442.227697] ------------[ cut here ]------------
> > > [ 442.228176] Badness at fs/sysfs/dir.c:487
> > > [ 442.228642] NIP: c00eb71c LR: c00eb71c CTR: 00000000
> > > [ 442.229117] REGS: eea0fa50 TRAP: 0700 Not tainted (2.6.33-rc3)
> > > [ 442.229592] MSR: 00029032 <EE,ME,CE,IR,DR> CR: 42008444 XER: 00000000
> > > [ 442.230151] TASK = eea10000[2821] 'modprobe' THREAD: eea0e000
> > > [ 442.230191] GPR00: c00eb71c eea0fb00 eea10000 0000004c 000064c6 ffffffff ffffffff 00000000
> > > [ 442.230758] GPR08: efa71740 c03e0000 00000000 000064c6 44008428 10020390 100e0000 100df49c
> > > [ 442.231326] GPR16: 100b54c0 100df49c 100ddd20 1018fb08 100b5340 c03e674c c03e6720 c03ea044
> > > [ 442.231902] GPR24: 00000000 24008422 ffffffea eea0fb58 ef0e9000 ef0e9000 ef0a9ea0 ffffffef
> > > [ 442.233187] NIP [c00eb71c] sysfs_add_one+0x94/0xc0
> > > [ 442.233695] LR [c00eb71c] sysfs_add_one+0x94/0xc0
> > > [ 442.234363] Call Trace:
> > >
> > > I've put the whole dmesg on:
> > >
> > > http://nerdbynature.de/bits/2.6.33-rc2/i2c_powermac/r1/
> >
> > Hmm. Looks like a different but somewhat similar problem in the ams
> > driver: some code that is in ams_exit() (the module exit code) should
> > instead be called when the device (not module) is removed. It probably
> > doesn't make much of a difference in the PMU case, but in the I2C case
> > it does matter.
> >
> > The following, totally untested patch may fix it. I make no guarantee
> > that my code isn't racy though, I'm not familiar enough with the ams
> > driver code to tell for sure.
> >
> > ---
> > drivers/hwmon/ams/ams-core.c | 11 +++++++----
> > drivers/hwmon/ams/ams-i2c.c | 2 ++
> > drivers/hwmon/ams/ams-pmu.c | 2 ++
> > drivers/hwmon/ams/ams.h | 1 +
> > 4 files changed, 12 insertions(+), 4 deletions(-)
> >
> > --- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-core.c 2009-06-10 05:05:27.000000000 +0200
> > +++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-core.c 2010-01-07 17:14:25.000000000 +0100
> > @@ -213,7 +213,7 @@ int __init ams_init(void)
> > return -ENODEV;
> > }
> >
> > -void ams_exit(void)
> > +void ams_sensor_detach(void)
> > {
> > /* Remove input device */
> > ams_input_exit();
> > @@ -221,9 +221,6 @@ void ams_exit(void)
> > /* Remove attributes */
> > device_remove_file(&ams_info.of_dev->dev, &dev_attr_current);
> >
> > - /* Shut down implementation */
> > - ams_info.exit();
> > -
> > /* Flush interrupt worker
> > *
> > * We do this after ams_info.exit(), because an interrupt might
> > @@ -239,6 +236,12 @@ void ams_exit(void)
> > pmf_unregister_irq_client(&ams_freefall_client);
> > }
> >
> > +static void __exit ams_exit(void)
> > +{
> > + /* Shut down implementation */
> > + ams_info.exit();
> > +}
> > +
> > MODULE_AUTHOR("Stelian Pop, Michael Hanselmann");
> > MODULE_DESCRIPTION("Apple Motion Sensor driver");
> > MODULE_LICENSE("GPL");
> > --- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-i2c.c 2009-06-10 05:05:27.000000000 +0200
> > +++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-i2c.c 2010-01-07 17:12:46.000000000 +0100
> > @@ -238,6 +238,8 @@ static int ams_i2c_probe(struct i2c_clie
> > static int ams_i2c_remove(struct i2c_client *client)
> > {
> > if (ams_info.has_device) {
> > + ams_sensor_detach();
> > +
> > /* Disable interrupts */
> > ams_i2c_set_irq(AMS_IRQ_ALL, 0);
> >
> > --- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-pmu.c 2009-06-10 05:05:27.000000000 +0200
> > +++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-pmu.c 2010-01-07 17:13:47.000000000 +0100
> > @@ -133,6 +133,8 @@ static void ams_pmu_get_xyz(s8 *x, s8 *y
> >
> > static void ams_pmu_exit(void)
> > {
> > + ams_sensor_detach();
> > +
> > /* Disable interrupts */
> > ams_pmu_set_irq(AMS_IRQ_ALL, 0);
> >
> > --- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams.h 2009-06-10 05:05:27.000000000 +0200
> > +++ linux-2.6.33-rc3/drivers/hwmon/ams/ams.h 2010-01-07 17:11:43.000000000 +0100
> > @@ -61,6 +61,7 @@ extern struct ams ams_info;
> >
> > extern void ams_sensors(s8 *x, s8 *y, s8 *z);
> > extern int ams_sensor_attach(void);
> > +extern void ams_sensor_detach(void);
> >
> > extern int ams_pmu_init(struct device_node *np);
> > extern int ams_i2c_init(struct device_node *np);
>
> Christian, did you ever test this second patch of mine? If you did,
> what was the outcome?
>
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Andrew Morton @ 2010-01-29 23:49 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, David Woodhouse
In-Reply-To: <OF871F5B59.C2574563-ONC12576B9.00300E39-C12576B9.0030C51C@transmode.se>
On Thu, 28 Jan 2010 09:52:41 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the
> new optimized inflate only available on arch's that
> define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This
> will again enable the optimization for all arch's by
> by defining our own endian independent version
> of unaligned access. As an added bonus, arch's that
> define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS do a
> plain load instead.
Given that we're at -rc5, that changelog says to me "this is a 2.6.34
patch".
If that is wrong, please tell me why.
^ permalink raw reply
* [PATCH] powerpc: Add a new platform for maple so a different link address can be set
From: Corey Minyard @ 2010-01-30 0:18 UTC (permalink / raw)
To: linuxppc-dev
From: Corey Minyard <cminyard@mvista.com>
The maple platform failed to load because it's firmware could not take a
link address of 0x4000000. A new platform type with a link address of
0x400000 had to be created for the maple.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
---
Without this patch the firmware loader says it is unable to parse the
ELF header and dies. This patch lets 2.6.31 boot without issue. At
the current head of k.org git, at least with an NFS mount, I'm getting:
Kernel panic - not syncing: No init found
So I'm not sure what the deal is there, but this patch is still required
to get the firmware to load the kernel.
Index: linux-2.6.31/arch/powerpc/boot/wrapper
===================================================================
--- linux-2.6.31.orig/arch/powerpc/boot/wrapper
+++ linux-2.6.31/arch/powerpc/boot/wrapper
@@ -145,6 +145,10 @@ pseries)
platformo=$object/of.o
link_address='0x4000000'
;;
+maple)
+ platformo=$object/of.o
+ link_address='0x400000'
+ ;;
pmac|chrp)
platformo=$object/of.o
;;
@@ -313,7 +319,7 @@ fi
# post-processing needed for some platforms
case "$platform" in
-pseries|chrp)
+pseries|chrp|maple)
$objbin/addnote "$ofile"
;;
coff)
Index: linux-2.6.31/arch/powerpc/boot/Makefile
===================================================================
--- linux-2.6.31.orig/arch/powerpc/boot/Makefile
+++ linux-2.6.31/arch/powerpc/boot/Makefile
@@ -167,7 +167,7 @@ quiet_cmd_wrap = WRAP $@
$(if $3, -s $3)$(if $4, -d $4)$(if $5, -i $5) vmlinux
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
-image-$(CONFIG_PPC_MAPLE) += zImage.pseries
+image-$(CONFIG_PPC_MAPLE) += zImage.maple
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
image-$(CONFIG_PPC_PS3) += dtbImage.ps3
image-$(CONFIG_PPC_CELLEB) += zImage.pseries
@@ -346,7 +346,7 @@ install: $(CONFIGURE) $(addprefix $(obj)
clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
- simpleImage.* otheros.bld *.dtb
+ zImage.maple simpleImage.* otheros.bld *.dtb
# clean up files cached by wrapper
clean-kernel := vmlinux.strip vmlinux.bin
^ permalink raw reply
* [PATCH] powerpc: Add DMA mask to MPSC serial and network and UART device to serial
From: Corey Minyard @ 2010-01-30 0:04 UTC (permalink / raw)
To: linuxppc-dev
From: Corey Minyard <cminyard@mvista.com>
The MPSC drivers that use DMA need to set coherent_dma_mask to allow
dma_alloc_xxx routines to work properly. Also, the mpsc serial driver
needed to set pi->port.dev to register properly. With these fixes,
the MPSC drivers seem to work again.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
---
I'm not really sure about where to set the coherent_dma_mask, it seems
like a more general place would be better but I couldn't find it.
Without these, the console stops working after the switchover and
the network driver fails to allocate buffers. With these, my board
boots up and works fine.
Index: linux-2.6.31/drivers/serial/mpsc.c
===================================================================
--- linux-2.6.31.orig/drivers/serial/mpsc.c
+++ linux-2.6.31/drivers/serial/mpsc.c
@@ -2071,6 +2071,9 @@ static int mpsc_drv_probe(struct platfor
if (!(rc = mpsc_drv_map_regs(pi, dev))) {
mpsc_drv_get_platform_data(pi, dev, dev->id);
+ dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ pi->port.dev = &dev->dev;
+
if (!(rc = mpsc_make_ready(pi))) {
spin_lock_init(&pi->tx_lock);
if (!(rc = uart_add_one_port(&mpsc_reg,
Index: linux-2.6.31/drivers/net/mv643xx_eth.c
===================================================================
--- linux-2.6.31.orig/drivers/net/mv643xx_eth.c
+++ linux-2.6.31/drivers/net/mv643xx_eth.c
@@ -2916,7 +2916,7 @@ static int mv643xx_eth_probe(struct plat
mp->shared = platform_get_drvdata(pd->shared);
mp->base = mp->shared->base + 0x0400 + (pd->port_number << 10);
mp->port_num = pd->port_number;
-
+ pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
mp->dev = dev;
set_params(mp, pd);
^ permalink raw reply
* Re: i2c_powermac: Kernel access of bad area
From: Christian Kujau @ 2010-01-30 6:03 UTC (permalink / raw)
To: Jean Delvare; +Cc: Stelian Pop, Michael Hanselmann, LKML, linuxppc-dev
In-Reply-To: <20100129091857.3b7228db@hyperion.delvare>
On Fri, 29 Jan 2010 at 09:18, Jean Delvare wrote:
> Christian, did you ever test this second patch of mine? If you did,
> what was the outcome?
Sorry, I must've missed that 2nd patch of yours. I'll test this now and
report back.
Thanks,
Christian.
--
BOFH excuse #112:
The monitor is plugged into the serial port
^ permalink raw reply
* Re: i2c_powermac: Kernel access of bad area
From: Jean Delvare @ 2010-01-30 9:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christian Kujau, linuxppc-dev, Michael Hanselmann, LKML,
Stelian Pop
In-Reply-To: <1264800895.20211.120.camel@pasglop>
On Sat, 30 Jan 2010 08:34:55 +1100, Benjamin Herrenschmidt wrote:
>
> > Ben, what about applying this patch of mine, as Christian reported it
> > fixed his oops?
>
> Sure. I never quite know with i2c which ones you will apply directly and
> which ones you want to go through my tree :-)
>
> Hopefully they should still be referened on patchwork, I'll dig there
> and pick them up.
Well, basically I pick patches that touch drivers/i2c/*, and I don't
pick patches that touch drivers/macintosh/*. When I can't build the
drivers, I don't really feel like pushing the patches myself.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Joakim Tjernlund @ 2010-01-30 10:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Roel Kluin, linuxppc-dev@ozlabs.org list,
Richard Purdie, Anton Blanchard, David Woodhouse
In-Reply-To: <20100129154924.d1bf8bc3.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote on 2010/01/30 00:49:24:
>
> On Thu, 28 Jan 2010 09:52:41 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the
> > new optimized inflate only available on arch's that
> > define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This
> > will again enable the optimization for all arch's by
> > by defining our own endian independent version
> > of unaligned access. As an added bonus, arch's that
> > define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS do a
> > plain load instead.
>
> Given that we're at -rc5, that changelog says to me "this is a 2.6.34
> patch".
>
> If that is wrong, please tell me why.
2.6.34 is fine, thanks.
Jocke
^ permalink raw reply
* [PATCH] powerpc: TIF_ABI_PENDING bit removal
From: Andreas Schwab @ 2010-01-30 20:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
Here are the powerpc bits to remove TIF_ABI_PENDING now that
set_personality() is called at the appropriate place in exec.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
arch/powerpc/include/asm/elf.h | 8 ++------
arch/powerpc/include/asm/thread_info.h | 2 --
arch/powerpc/kernel/process.c | 12 ------------
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 17828ad..c376eda 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -235,14 +235,10 @@ typedef elf_vrregset_t elf_fpxregset_t;
#ifdef __powerpc64__
# define SET_PERSONALITY(ex) \
do { \
- unsigned long new_flags = 0; \
if ((ex).e_ident[EI_CLASS] == ELFCLASS32) \
- new_flags = _TIF_32BIT; \
- if ((current_thread_info()->flags & _TIF_32BIT) \
- != new_flags) \
- set_thread_flag(TIF_ABI_PENDING); \
+ set_thread_flag(TIF_32BIT); \
else \
- clear_thread_flag(TIF_ABI_PENDING); \
+ clear_thread_flag(TIF_32BIT); \
if (personality(current->personality) != PER_LINUX32) \
set_personality(PER_LINUX | \
(current->personality & (~PER_MASK))); \
diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
index c8b3292..aa9d383 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -111,7 +111,6 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_NOTIFY_RESUME 13 /* callback before returning to user */
#define TIF_FREEZE 14 /* Freezing for suspend */
#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
-#define TIF_ABI_PENDING 16 /* 32/64 bit switch needed */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
@@ -129,7 +128,6 @@ static inline struct thread_info *current_thread_info(void)
#define _TIF_NOTIFY_RESUME (1<<TIF_NOTIFY_RESUME)
#define _TIF_FREEZE (1<<TIF_FREEZE)
#define _TIF_RUNLATCH (1<<TIF_RUNLATCH)
-#define _TIF_ABI_PENDING (1<<TIF_ABI_PENDING)
#define _TIF_SYSCALL_T_OR_A (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP)
#define _TIF_USER_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED | \
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index c930ac3..7b816da 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -554,18 +554,6 @@ void exit_thread(void)
void flush_thread(void)
{
-#ifdef CONFIG_PPC64
- struct thread_info *t = current_thread_info();
-
- if (test_ti_thread_flag(t, TIF_ABI_PENDING)) {
- clear_ti_thread_flag(t, TIF_ABI_PENDING);
- if (test_ti_thread_flag(t, TIF_32BIT))
- clear_ti_thread_flag(t, TIF_32BIT);
- else
- set_ti_thread_flag(t, TIF_32BIT);
- }
-#endif
-
discard_lazy_cpu_state();
if (current->thread.dabr) {
--
1.6.6.1
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
From: Frederic Weisbecker @ 2010-01-30 20:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: shaggy, David Gibson, prasad, LKML, linuxppc-dev
In-Reply-To: <1264365121.3601.43.camel@pasglop>
On Mon, Jan 25, 2010 at 07:32:00AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-01-25 at 00:48 +0530, K.Prasad wrote:
> >
> > Some of the benefits of using these generic interfaces include:
> > - Interoperability with other users of debug register (such as
> > parallel
> > kernel requests) i.e. non-exclusive use of debug registers.
> > - Enables debugging/tracing tools such as perf-events and ftrace to
> > make
> > use of debug registers.
> > - Re-use of common code available in kernel (kernel/hw_breakpoint.c).
> >
> > Let me know what you think.
>
> This might have changed but last I looked the "generic" breakpoint
> interface was still too x86-centric and wasn't capable of expressing
> some of the features of the BookE debug register set such as the data
> value compare, the ranged breakpoints, etc...
We have one field for addr, one for len and one for the memory access
type.
I think that those three are enough to express breakpoint ranges.
Basically a breakpoint range is a breakpoint that can have a high
len.
I've looked at the G2 PowerPc core breakpoint implementation, just to
face one of such tricky examples.
We have DABR and DABR2 for watchpoint (and respectively IABR and IABR2
for ins breakpoints). Those host the addresses to target, or well,
let's rather call them "address operand" registers. To generalize, I
call these xABR and xABR2 as it seems instruction and data breakpoint
work the same, they just have their own dedicated registers.
Then you have DBCR/IBCR (let's call them xBCR) which control the
breakpoints, with two fields in each that detail the operators to affect
in the address operands registers. You can choose betwen ==, <, or >= .
Another field in the operator is the SIG_TYPE, which describes the
combination, either "matches xABR AND xABR2" or "matches xABR OR xABR2".
If you choose the "OR" SIG_TYPE, it makes no sense to use the < or >=
operators on the addresses operands in practice. Who needs the following
matches?
addr < xABR || addr >= xABR2
addr < xABR || addr < xABR2
addr >= xABR || addr >= xABR2
The only operator that makes sense in a OR type is ==, which
basically provides you two breakpoints:
addr == xABR || addr == xABR2
Now if you choose the "AND" SIG_TYPE, the following matches
make no sense:
addr < xABR && addr < xABR2
addr < xABR && addr >= xABR2 (if xABR < xABR2)
addr == xABR && addr (>=,<) xABR2
Basically, it's only usable for delimited ranges:
addr >= xABR && addr < xABR2 (xABR < xABR2)
So the comparison is a trick that can actually only have
a practical use to define two exact matching breakpoints
or a delimited breakpoint range.
Hence, unless I'm missing something obvious, the current
generic interface is sufficient to express that.
I may also miss other kind of implementation that could
have other requirements.
> I'd rather have this more dedicated and more complete interface merged
> for gdb's sake, and in a second step look at unifying.
Perhaps. Supporting ptrace breakpoints should be an easy first
step as it's basically the responsibility of the user to fill
the registers, but it's a pretty limited scope work, especially you
won't have perf support.
> I believe that the generic breakpoint infrastructure should not be the
> mid-layer. IE. It cannot be made in any clean shape of form, to express
> all of the subtle features that a given architecture or platform can
> support and as such would always be inferior to a dedicated one.
Actually I think the current interface already does, as I explained
above.
What is broken for any other architectures than x86 is the set
of constraints, but I can easily move it to the arch, unless
I find a good generic solution (or a cool combination between
both).
> I can see the interest in exposing some kind of generic API that
> implements a common subset of breakpoint or watchpoint facilities to
> generic code such as the event tracer. This could be layered on top of
> an arch specific mechanism
>
> But having the generic mechanism at the core for everybody is another
> attempt of "make everybody look like x86" which I believe in this case
> is sub optimal.
Not at all. It's an attempt to make a generic interface that can
exploit at best _each_ arch specific features. Other than the set
of constraints that I'm going to rework, the generic interface is powerful
enough to host what I've seen in term of cpu breakpoints implementations
for now. But if it's actually not and I'm missing other cases, please
report it to me.
The reason that makes the current generic constraints x86
oriented only is that I've only x86 boxes at home and I needed
to make a first shot without knowing anything about other archs
constraints, but in the long term, our motivations (Prasad's and mines)
are definetely not archX-centric.
^ permalink raw reply
* Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
From: Benjamin Herrenschmidt @ 2010-01-30 21:33 UTC (permalink / raw)
To: Frederic Weisbecker; +Cc: shaggy, David Gibson, prasad, LKML, linuxppc-dev
In-Reply-To: <20100130204409.GE5675@nowhere>
> We have one field for addr, one for len and one for the memory access
> type.
>
> I think that those three are enough to express breakpoint ranges.
> Basically a breakpoint range is a breakpoint that can have a high
> len.
>
> I've looked at the G2 PowerPc core breakpoint implementation, just to
> face one of such tricky examples.
BookE has a richer semantic. We have watchpoints with data value compare
for example, we also have instruction value compare for breakpoints, and
a few other niceties. There's also subtle differences between what
processor variants support.
.../...
> > I'd rather have this more dedicated and more complete interface merged
> > for gdb's sake, and in a second step look at unifying.
>
>
> Perhaps. Supporting ptrace breakpoints should be an easy first
> step as it's basically the responsibility of the user to fill
> the registers, but it's a pretty limited scope work, especially you
> won't have perf support.
But we can add it later.
> > I believe that the generic breakpoint infrastructure should not be the
> > mid-layer. IE. It cannot be made in any clean shape of form, to express
> > all of the subtle features that a given architecture or platform can
> > support and as such would always be inferior to a dedicated one.
>
>
> Actually I think the current interface already does, as I explained
> above.
>
> What is broken for any other architectures than x86 is the set
> of constraints, but I can easily move it to the arch, unless
> I find a good generic solution (or a cool combination between
> both).
Again, this is all "can do" vs. "already done and working". May I point
you to Linus recent rant against magic infrastructures that try to do
everything and do nothing right ? :-) I much prefer starting with
something dedicated that does exactly what is expected, have that
upstream (and in that regard the patches are good for the next merge
window) and -then- maybe look at how some of it could be re-used for
perf.
> Not at all. It's an attempt to make a generic interface that can
> exploit at best _each_ arch specific features.
That reminds me of the justifications for utrace :-) It might well be
but I very much doubt that is possible. In any case, it doesn't appear
to be there yet. So let's just get that stuff in so we have our
interface finally working, and we can look at doing fancy things with
perf in a second pass.
> Other than the set
> of constraints that I'm going to rework, the generic interface is powerful
> enough to host what I've seen in term of cpu breakpoints implementations
> for now. But if it's actually not and I'm missing other cases, please
> report it to me.
>
> The reason that makes the current generic constraints x86
> oriented only is that I've only x86 boxes at home and I needed
> to make a first shot without knowing anything about other archs
> constraints, but in the long term, our motivations (Prasad's and mines)
> are definetely not archX-centric.
Cheers,
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2010-01-30 23:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list
Hi Linus !
Here are some more defconfig updates that I missed before LCA and a
few PCI related fixes, some of them actually fixing regressions and
one of them (the 4xx one) trivial enough that's really not worth
delaying it.
Cheers,
Ben.
The following changes since commit b04da8bfdfbbd79544cab2fadfdc12e87eb01600:
Greg Kroah-Hartman (1):
fnctl: f_modown should call write_lock_irqsave/restore
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (4):
powerpc/pci: Add calls to set_pcie_port_type() and set_pcie_hotplug_bridge()
powerpc/pci: Add missing hookup to pci_slot
powerpc/pci: Add missing call to header fixup
Merge commit 'jwb/merge' into merge
Josh Boyer (2):
powerpc/44x: Update PowerPC 44x board defconfigs
powerpc/40x: Update the PowerPC 40x board defconfigs
Stef van Os (1):
powerpc/4xx: Add pcix type 1 transactions
arch/powerpc/configs/40x/acadia_defconfig | 241 ++++++++++++++-----
arch/powerpc/configs/40x/ep405_defconfig | 307 ++++++++++++++++++------
arch/powerpc/configs/40x/hcu4_defconfig | 256 +++++++++++++++-----
arch/powerpc/configs/40x/kilauea_defconfig | 140 ++++++++---
arch/powerpc/configs/40x/makalu_defconfig | 190 ++++++++++-----
arch/powerpc/configs/40x/walnut_defconfig | 257 +++++++++++++++-----
arch/powerpc/configs/44x/arches_defconfig | 135 ++++++++---
arch/powerpc/configs/44x/bamboo_defconfig | 255 +++++++++++++++-----
arch/powerpc/configs/44x/canyonlands_defconfig | 141 ++++++++---
arch/powerpc/configs/44x/ebony_defconfig | 258 +++++++++++++++-----
arch/powerpc/configs/44x/eiger_defconfig | 128 +++++++---
arch/powerpc/configs/44x/katmai_defconfig | 253 +++++++++++++++-----
arch/powerpc/configs/44x/rainier_defconfig | 254 +++++++++++++++-----
arch/powerpc/configs/44x/redwood_defconfig | 274 +++++++++++++++------
arch/powerpc/configs/44x/sam440ep_defconfig | 284 +++++++++++++++-------
arch/powerpc/configs/44x/sequoia_defconfig | 202 +++++++++++-----
arch/powerpc/configs/44x/taishan_defconfig | 258 +++++++++++++++-----
arch/powerpc/configs/44x/warp_defconfig | 228 ++++++++++++------
arch/powerpc/configs/ppc40x_defconfig | 292 ++++++++++++++++-------
arch/powerpc/configs/ppc44x_defconfig | 309 +++++++++++++++++-------
arch/powerpc/kernel/pci_of_scan.c | 10 +
arch/powerpc/sysdev/ppc4xx_pci.c | 3 +-
drivers/pci/probe.c | 4 +-
include/linux/pci.h | 4 +
24 files changed, 3409 insertions(+), 1274 deletions(-)
^ permalink raw reply
* Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
From: Frederic Weisbecker @ 2010-01-31 1:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: shaggy, David Gibson, prasad, LKML, linuxppc-dev
In-Reply-To: <1264887205.8287.5.camel@pasglop>
On Sun, Jan 31, 2010 at 08:33:25AM +1100, Benjamin Herrenschmidt wrote:
>
> > We have one field for addr, one for len and one for the memory access
> > type.
> >
> > I think that those three are enough to express breakpoint ranges.
> > Basically a breakpoint range is a breakpoint that can have a high
> > len.
> >
> > I've looked at the G2 PowerPc core breakpoint implementation, just to
> > face one of such tricky examples.
>
> BookE has a richer semantic. We have watchpoints with data value compare
> for example, we also have instruction value compare for breakpoints, and
> a few other niceties. There's also subtle differences between what
> processor variants support.
>
> .../...
Ah indeed, I missed the data value compare thing. Especially how
it is implemented won't make things easy.
This is basically a comparison against chosen bytes of the data,
with or/and patterns.
Not sure what the "or" can be useful for.
That won't be easy to implement in the generic interface, looking
at how it is done in the BookE.
There is also the address comparison by mask.
Anyway, I think we can add fields in the interface to provide
such features, but we can't support all of them given, as you
said, the subtle differences between different cpu.
For example I think it can be useful to implement support
for data comparison, by mask for example. But I don't imagine
useful usecases to compare byte 4 and byte1 and trigger an event
if one OR other match.
I think we are going to implement what has obvious usecases
(parts of such data comparisons, parts of address mask
comparison) in the generic interface: the fields in perf_attr
that can be filled by perf in userspace.
And the rest can be implemented from the hw_perf_event structure
which contains the arch structure and can then be filled by ptrace at
will.
>
> > > I'd rather have this more dedicated and more complete interface merged
> > > for gdb's sake, and in a second step look at unifying.
> >
> >
> > Perhaps. Supporting ptrace breakpoints should be an easy first
> > step as it's basically the responsibility of the user to fill
> > the registers, but it's a pretty limited scope work, especially you
> > won't have perf support.
>
> But we can add it later.
Yeah you're right. Having a raw ptrace support is a first
useful step that won't be a barrier to enhance it further
through the generic API.
> > > I believe that the generic breakpoint infrastructure should not be the
> > > mid-layer. IE. It cannot be made in any clean shape of form, to express
> > > all of the subtle features that a given architecture or platform can
> > > support and as such would always be inferior to a dedicated one.
> >
> >
> > Actually I think the current interface already does, as I explained
> > above.
> >
> > What is broken for any other architectures than x86 is the set
> > of constraints, but I can easily move it to the arch, unless
> > I find a good generic solution (or a cool combination between
> > both).
>
> Again, this is all "can do" vs. "already done and working". May I point
> you to Linus recent rant against magic infrastructures that try to do
> everything and do nothing right ? :-) I much prefer starting with
> something dedicated that does exactly what is expected, have that
> upstream (and in that regard the patches are good for the next merge
> window) and -then- maybe look at how some of it could be re-used for
> perf.
Sure I'm not against a first raw ptrace support. As I said,
this is not a barrier for what comes next.
Now for the rest, I don't think this is the same story than
utrace.
Trying to have a generic layer for a hardware feature implemented
differently across archs can't be called something that tries to do
everything. Otherwise you can oppose these arguments to everything
that is not in the arch/ directories. No generic irq layer, no
generic timer, etc...
We need this generic layer because we want the breakpoints
to be available for wider uses than ptrace. If there was only
ptrace, I would really agree with you that it's not worth the
generic layer.
It's just that breakpoints are a set of possible features, but each
archs implement its own subset among the possible features. x86
is one of the weakest there, and since this generic layer has been
first x86 oriented, it looks too weak to host the most interesting
possibilities.
Let it grow a bit, it's still young.
> > Not at all. It's an attempt to make a generic interface that can
> > exploit at best _each_ arch specific features.
>
> That reminds me of the justifications for utrace :-) It might well be
> but I very much doubt that is possible. In any case, it doesn't appear
> to be there yet.
You are too pessimistic ;-)
I don't think we can express every possibilities through the generic
interface. But we can express the most interesting ones for profiling
uses.
The rest (ptrace) can still be expressed through the arch part of the perf
events.
> So let's just get that stuff in so we have our
> interface finally working, and we can look at doing fancy things with
> perf in a second pass.
Sure.
^ permalink raw reply
* Re: i2c_powermac: Kernel access of bad area
From: Christian Kujau @ 2010-01-31 6:05 UTC (permalink / raw)
To: Jean Delvare; +Cc: Stelian Pop, Michael Hanselmann, LKML, linuxppc-dev
In-Reply-To: <alpine.DEB.2.01.1001292202150.3483@bogon.housecafe.de>
On Fri, 29 Jan 2010 at 22:03, Christian Kujau wrote:
> On Fri, 29 Jan 2010 at 09:18, Jean Delvare wrote:
> > Christian, did you ever test this second patch of mine? If you did,
> > what was the outcome?
OK, I've now applied both the drivers/hwmon/ams/ patches and your earlier
one for drivers/macintosh/therm_adt746x.c [0] to a current -git checkout
and now I can unload i2c_powermac, list and read the remaining files in
/sys/devices/temperatures, load i2c_powermac again, and unload, and
load, and ... - it's wonderful! :-) No oopses so far.
Feel free to add a Tested-by: Christian Kujau <lists@nerdbynature.de>
so that the patches can be pushed into mainline.
Thanks for the fixes, Jean!
Christian.
[0] http://nerdbynature.de/bits/2.6.33-rc2/i2c_powermac/r2/
--
BOFH excuse #337:
the butane lighter causes the pincushioning
^ permalink raw reply
* ping, was Re: [PATCH 1/2] pmac-zilog: add platform driver, version 3
From: fthain @ 2010-01-31 7:25 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <10f740e81001140538n67710bfr17d131a8f4b25137@mail.gmail.com>
Hi Geert,
As I understand it, this patch needs Ben's ack before it (and the others)
can be merged into linux-next (?)
Finn
On Thu, 14 Jan 2010, Geert Uytterhoeven wrote:
> Thanks, applied.
>
> Gr{oetje,eeting}s,
>
> Geert
^ permalink raw reply
* Re: ping, was Re: [PATCH 1/2] pmac-zilog: add platform driver, version 3
From: Geert Uytterhoeven @ 2010-01-31 9:03 UTC (permalink / raw)
To: fthain; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <alpine.LNX.2.00.1001311820070.5428@nippy.intranet>
On Sun, Jan 31, 2010 at 08:25, <fthain@telegraphics.com.au> wrote:
> As I understand it, this patch needs Ben's ack before it (and the others)
> can be merged into linux-next (?)
He gave his ack on IRC. Still have to add them to m68k-queue and
for-next, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: i2c_powermac: Kernel access of bad area
From: Jean Delvare @ 2010-01-31 9:52 UTC (permalink / raw)
To: Christian Kujau; +Cc: Stelian Pop, Michael Hanselmann, LKML, linuxppc-dev
In-Reply-To: <alpine.DEB.2.01.1001302156380.3483@bogon.housecafe.de>
On Sat, 30 Jan 2010 22:05:26 -0800 (PST), Christian Kujau wrote:
> OK, I've now applied both the drivers/hwmon/ams/ patches and your earlier
> one for drivers/macintosh/therm_adt746x.c [0] to a current -git checkout
> and now I can unload i2c_powermac, list and read the remaining files in
> /sys/devices/temperatures, load i2c_powermac again, and unload, and
> load, and ... - it's wonderful! :-) No oopses so far.
>
> Feel free to add a Tested-by: Christian Kujau <lists@nerdbynature.de>
> so that the patches can be pushed into mainline.
Thanks, I'll resend both patches with proper comments and headers now.
> Thanks for the fixes, Jean!
You're welcome.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
^ permalink raw reply
* [PATCH 1/5] powerpc: Rework /proc/interrupts
From: Anton Blanchard @ 2010-01-31 11:09 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
On a large machine I noticed the columns of /proc/interrupts failed to line up
with the header after CPU9. At sufficiently large numbers of CPUs it becomes
impossible to line up the CPU number with the counts.
While fixing this I noticed x86 has a number of updates that we may as well
pull in. On PowerPC we currently omit an interrupt completely if there is no
active handler, whereas on x86 it is printed if there is a non zero count.
The x86 code also spaces the first column correctly based on nr_irqs.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
This patch follows on from "powerpc: Reduce footprint of irq_stat" and
"powerpc: Reduce footprint of xics_ipi_struct"
Index: linux-cpumask/arch/powerpc/kernel/irq.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/kernel/irq.c 2010-01-30 19:56:31.650960989 +1100
+++ linux-cpumask/arch/powerpc/kernel/irq.c 2010-01-30 22:31:00.037227967 +1100
@@ -183,30 +183,46 @@ notrace void raw_local_irq_restore(unsig
EXPORT_SYMBOL(raw_local_irq_restore);
#endif /* CONFIG_PPC64 */
+static int show_other_interrupts(struct seq_file *p, int prec)
+{
+ int j;
+
+#if defined(CONFIG_PPC32) && defined(CONFIG_TAU_INT)
+ if (tau_initialized) {
+ seq_printf(p, "%*s: ", prec, "TAU");
+ for_each_online_cpu(j)
+ seq_printf(p, "%10u ", tau_interrupts(j));
+ seq_puts(p, " PowerPC Thermal Assist (cpu temp)\n");
+ }
+#endif /* CONFIG_PPC32 && CONFIG_TAU_INT */
+
+ seq_printf(p, "%*s: %10u\n", prec, "BAD", ppc_spurious_interrupts);
+
+ return 0;
+}
+
int show_interrupts(struct seq_file *p, void *v)
{
- int i = *(loff_t *)v, j;
+ unsigned long flags, any_count = 0;
+ int i = *(loff_t *) v, j, prec;
struct irqaction *action;
struct irq_desc *desc;
- unsigned long flags;
+ if (i > nr_irqs)
+ return 0;
+
+ for (prec = 3, j = 1000; prec < 10 && j <= nr_irqs; ++prec)
+ j *= 10;
+
+ if (i == nr_irqs)
+ return show_other_interrupts(p, prec);
+
+ /* print header */
if (i == 0) {
- seq_puts(p, " ");
+ seq_printf(p, "%*s", prec + 8, "");
for_each_online_cpu(j)
- seq_printf(p, "CPU%d ", j);
+ seq_printf(p, "CPU%-8d", j);
seq_putc(p, '\n');
- } else if (i == nr_irqs) {
-#if defined(CONFIG_PPC32) && defined(CONFIG_TAU_INT)
- if (tau_initialized){
- seq_puts(p, "TAU: ");
- for_each_online_cpu(j)
- seq_printf(p, "%10u ", tau_interrupts(j));
- seq_puts(p, " PowerPC Thermal Assist (cpu temp)\n");
- }
-#endif /* CONFIG_PPC32 && CONFIG_TAU_INT*/
- seq_printf(p, "BAD: %10u\n", ppc_spurious_interrupts);
-
- return 0;
}
desc = irq_to_desc(i);
@@ -214,34 +230,31 @@ int show_interrupts(struct seq_file *p,
return 0;
raw_spin_lock_irqsave(&desc->lock, flags);
-
+ for_each_online_cpu(j)
+ any_count |= kstat_irqs_cpu(i, j);
action = desc->action;
- if (!action || !action->handler)
- goto skip;
+ if (!action && !any_count)
+ goto out;
- seq_printf(p, "%3d: ", i);
-#ifdef CONFIG_SMP
+ seq_printf(p, "%*d: ", prec, i);
for_each_online_cpu(j)
seq_printf(p, "%10u ", kstat_irqs_cpu(i, j));
-#else
- seq_printf(p, "%10u ", kstat_irqs(i));
-#endif /* CONFIG_SMP */
if (desc->chip)
- seq_printf(p, " %s ", desc->chip->name);
+ seq_printf(p, " %-16s", desc->chip->name);
else
- seq_puts(p, " None ");
+ seq_printf(p, " %-16s", "None");
+ seq_printf(p, " %-8s", (desc->status & IRQ_LEVEL) ? "Level" : "Edge");
- seq_printf(p, "%s", (desc->status & IRQ_LEVEL) ? "Level " : "Edge ");
- seq_printf(p, " %s", action->name);
+ if (action) {
+ seq_printf(p, " %s", action->name);
+ while ((action = action->next) != NULL)
+ seq_printf(p, ", %s", action->name);
+ }
- for (action = action->next; action; action = action->next)
- seq_printf(p, ", %s", action->name);
seq_putc(p, '\n');
-
-skip:
+out:
raw_spin_unlock_irqrestore(&desc->lock, flags);
-
return 0;
}
^ permalink raw reply
* [PATCH 2/5] powerpc: Remove whitespace in irq chip name fields
From: Anton Blanchard @ 2010-01-31 11:10 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20100131110938.GL2996@kryten>
Now we use printf style alignment there is no need to manually space
these fields.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-cpumask/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c 2010-01-30 19:56:29.019715672 +1100
+++ linux-cpumask/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c 2010-01-30 19:56:34.010961169 +1100
@@ -79,7 +79,7 @@ cpld_unmask_irq(unsigned int irq)
}
static struct irq_chip cpld_pic = {
- .name = " CPLD PIC ",
+ .name = "CPLD PIC",
.mask = cpld_mask_irq,
.ack = cpld_mask_irq,
.unmask = cpld_unmask_irq,
Index: linux-cpumask/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/platforms/85xx/socrates_fpga_pic.c 2010-01-30 19:56:29.079716769 +1100
+++ linux-cpumask/arch/powerpc/platforms/85xx/socrates_fpga_pic.c 2010-01-30 19:56:34.010961169 +1100
@@ -232,7 +232,7 @@ static int socrates_fpga_pic_set_type(un
}
static struct irq_chip socrates_fpga_pic_chip = {
- .name = " FPGA-PIC ",
+ .name = "FPGA-PIC",
.ack = socrates_fpga_pic_ack,
.mask = socrates_fpga_pic_mask,
.mask_ack = socrates_fpga_pic_mask_ack,
Index: linux-cpumask/arch/powerpc/platforms/cell/beat_interrupt.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/platforms/cell/beat_interrupt.c 2010-01-30 19:56:29.049717504 +1100
+++ linux-cpumask/arch/powerpc/platforms/cell/beat_interrupt.c 2010-01-30 19:56:34.010961169 +1100
@@ -110,7 +110,7 @@ static void beatic_end_irq(unsigned int
}
static struct irq_chip beatic_pic = {
- .name = " CELL-BEAT ",
+ .name = "CELL-BEAT",
.unmask = beatic_unmask_irq,
.mask = beatic_mask_irq,
.eoi = beatic_end_irq,
Index: linux-cpumask/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/platforms/cell/interrupt.c 2010-01-30 19:56:29.059714370 +1100
+++ linux-cpumask/arch/powerpc/platforms/cell/interrupt.c 2010-01-30 19:56:34.010961169 +1100
@@ -88,7 +88,7 @@ static void iic_eoi(unsigned int irq)
}
static struct irq_chip iic_chip = {
- .name = " CELL-IIC ",
+ .name = "CELL-IIC",
.mask = iic_mask,
.unmask = iic_unmask,
.eoi = iic_eoi,
@@ -133,7 +133,7 @@ static void iic_ioexc_cascade(unsigned i
static struct irq_chip iic_ioexc_chip = {
- .name = " CELL-IOEX",
+ .name = "CELL-IOEX",
.mask = iic_mask,
.unmask = iic_unmask,
.eoi = iic_ioexc_eoi,
Index: linux-cpumask/arch/powerpc/platforms/cell/spider-pic.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/platforms/cell/spider-pic.c 2010-01-30 19:56:29.049717504 +1100
+++ linux-cpumask/arch/powerpc/platforms/cell/spider-pic.c 2010-01-30 19:56:34.010961169 +1100
@@ -168,7 +168,7 @@ static int spider_set_irq_type(unsigned
}
static struct irq_chip spider_pic = {
- .name = " SPIDER ",
+ .name = "SPIDER",
.unmask = spider_unmask_irq,
.mask = spider_mask_irq,
.ack = spider_ack_irq,
Index: linux-cpumask/arch/powerpc/platforms/iseries/irq.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/platforms/iseries/irq.c 2010-01-30 19:56:29.009711380 +1100
+++ linux-cpumask/arch/powerpc/platforms/iseries/irq.c 2010-01-30 19:56:34.010961169 +1100
@@ -273,7 +273,7 @@ static void iseries_end_IRQ(unsigned int
}
static struct irq_chip iseries_pic = {
- .name = "iSeries irq controller",
+ .name = "iSeries",
.startup = iseries_startup_IRQ,
.shutdown = iseries_shutdown_IRQ,
.unmask = iseries_enable_IRQ,
Index: linux-cpumask/arch/powerpc/platforms/powermac/pic.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/platforms/powermac/pic.c 2010-01-30 19:56:29.039711810 +1100
+++ linux-cpumask/arch/powerpc/platforms/powermac/pic.c 2010-01-30 19:56:34.010961169 +1100
@@ -195,7 +195,7 @@ static int pmac_retrigger(unsigned int v
}
static struct irq_chip pmac_pic = {
- .name = " PMAC-PIC ",
+ .name = "PMAC-PIC",
.startup = pmac_startup_irq,
.mask = pmac_mask_irq,
.ack = pmac_ack_irq,
Index: linux-cpumask/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/platforms/pseries/xics.c 2010-01-30 19:56:32.388460978 +1100
+++ linux-cpumask/arch/powerpc/platforms/pseries/xics.c 2010-01-30 19:56:34.010961169 +1100
@@ -428,7 +428,7 @@ static int xics_set_affinity(unsigned in
}
static struct irq_chip xics_pic_direct = {
- .name = " XICS ",
+ .name = "XICS",
.startup = xics_startup,
.mask = xics_mask_irq,
.unmask = xics_unmask_irq,
@@ -437,7 +437,7 @@ static struct irq_chip xics_pic_direct =
};
static struct irq_chip xics_pic_lpar = {
- .name = " XICS ",
+ .name = "XICS",
.startup = xics_startup,
.mask = xics_mask_irq,
.unmask = xics_unmask_irq,
Index: linux-cpumask/arch/powerpc/sysdev/cpm1.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/sysdev/cpm1.c 2010-01-30 19:56:29.129711920 +1100
+++ linux-cpumask/arch/powerpc/sysdev/cpm1.c 2010-01-30 19:56:34.010961169 +1100
@@ -77,7 +77,7 @@ static void cpm_end_irq(unsigned int irq
}
static struct irq_chip cpm_pic = {
- .name = " CPM PIC ",
+ .name = "CPM PIC",
.mask = cpm_mask_irq,
.unmask = cpm_unmask_irq,
.eoi = cpm_end_irq,
Index: linux-cpumask/arch/powerpc/sysdev/cpm2_pic.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/sysdev/cpm2_pic.c 2010-01-30 19:56:29.149713109 +1100
+++ linux-cpumask/arch/powerpc/sysdev/cpm2_pic.c 2010-01-30 19:56:34.010961169 +1100
@@ -198,7 +198,7 @@ err_sense:
}
static struct irq_chip cpm2_pic = {
- .name = " CPM2 SIU ",
+ .name = "CPM2 SIU",
.mask = cpm2_mask_irq,
.unmask = cpm2_unmask_irq,
.ack = cpm2_ack,
Index: linux-cpumask/arch/powerpc/sysdev/fsl_msi.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/sysdev/fsl_msi.c 2010-01-30 19:56:29.119713229 +1100
+++ linux-cpumask/arch/powerpc/sysdev/fsl_msi.c 2010-01-30 19:56:34.010961169 +1100
@@ -47,7 +47,7 @@ static struct irq_chip fsl_msi_chip = {
.mask = mask_msi_irq,
.unmask = unmask_msi_irq,
.ack = fsl_msi_end_irq,
- .name = " FSL-MSI ",
+ .name = "FSL-MSI",
};
static int fsl_msi_host_map(struct irq_host *h, unsigned int virq,
Index: linux-cpumask/arch/powerpc/sysdev/i8259.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/sysdev/i8259.c 2010-01-30 19:56:29.119713229 +1100
+++ linux-cpumask/arch/powerpc/sysdev/i8259.c 2010-01-30 19:56:34.010961169 +1100
@@ -135,7 +135,7 @@ static void i8259_unmask_irq(unsigned in
}
static struct irq_chip i8259_pic = {
- .name = " i8259 ",
+ .name = "i8259",
.mask = i8259_mask_irq,
.disable = i8259_mask_irq,
.unmask = i8259_unmask_irq,
Index: linux-cpumask/arch/powerpc/sysdev/ipic.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/sysdev/ipic.c 2010-01-30 19:56:29.089713470 +1100
+++ linux-cpumask/arch/powerpc/sysdev/ipic.c 2010-01-30 19:56:34.010961169 +1100
@@ -660,7 +660,7 @@ static int ipic_set_irq_type(unsigned in
/* level interrupts and edge interrupts have different ack operations */
static struct irq_chip ipic_level_irq_chip = {
- .name = " IPIC ",
+ .name = "IPIC",
.unmask = ipic_unmask_irq,
.mask = ipic_mask_irq,
.mask_ack = ipic_mask_irq,
@@ -668,7 +668,7 @@ static struct irq_chip ipic_level_irq_ch
};
static struct irq_chip ipic_edge_irq_chip = {
- .name = " IPIC ",
+ .name = "IPIC",
.unmask = ipic_unmask_irq,
.mask = ipic_mask_irq,
.mask_ack = ipic_mask_irq_and_ack,
Index: linux-cpumask/arch/powerpc/sysdev/mpc8xx_pic.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/sysdev/mpc8xx_pic.c 2010-01-30 19:56:29.109716536 +1100
+++ linux-cpumask/arch/powerpc/sysdev/mpc8xx_pic.c 2010-01-30 19:56:34.010961169 +1100
@@ -94,7 +94,7 @@ static int mpc8xx_set_irq_type(unsigned
}
static struct irq_chip mpc8xx_pic = {
- .name = " MPC8XX SIU ",
+ .name = "MPC8XX SIU",
.unmask = mpc8xx_unmask_irq,
.mask = mpc8xx_mask_irq,
.ack = mpc8xx_ack,
Index: linux-cpumask/arch/powerpc/sysdev/mpic_pasemi_msi.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/sysdev/mpic_pasemi_msi.c 2010-01-30 19:56:29.139718229 +1100
+++ linux-cpumask/arch/powerpc/sysdev/mpic_pasemi_msi.c 2010-01-30 19:56:34.010961169 +1100
@@ -60,7 +60,7 @@ static struct irq_chip mpic_pasemi_msi_c
.eoi = mpic_end_irq,
.set_type = mpic_set_irq_type,
.set_affinity = mpic_set_affinity,
- .name = "PASEMI-MSI ",
+ .name = "PASEMI-MSI",
};
static int pasemi_msi_check_device(struct pci_dev *pdev, int nvec, int type)
Index: linux-cpumask/arch/powerpc/sysdev/qe_lib/qe_ic.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/sysdev/qe_lib/qe_ic.c 2010-01-30 19:56:29.099711483 +1100
+++ linux-cpumask/arch/powerpc/sysdev/qe_lib/qe_ic.c 2010-01-30 19:56:34.010961169 +1100
@@ -237,7 +237,7 @@ static void qe_ic_mask_irq(unsigned int
}
static struct irq_chip qe_ic_irq_chip = {
- .name = " QEIC ",
+ .name = "QEIC",
.unmask = qe_ic_unmask_irq,
.mask = qe_ic_mask_irq,
.mask_ack = qe_ic_mask_irq,
Index: linux-cpumask/arch/powerpc/sysdev/uic.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/sysdev/uic.c 2010-01-30 19:56:29.089713470 +1100
+++ linux-cpumask/arch/powerpc/sysdev/uic.c 2010-01-30 19:56:34.010961169 +1100
@@ -177,7 +177,7 @@ static int uic_set_irq_type(unsigned int
}
static struct irq_chip uic_irq_chip = {
- .name = " UIC ",
+ .name = "UIC",
.unmask = uic_unmask_irq,
.mask = uic_mask_irq,
.mask_ack = uic_mask_ack_irq,
^ permalink raw reply
* [PATCH 3/5] powerpc: Add timer, performance monitor and machine check counts to /proc/interrupts
From: Anton Blanchard @ 2010-01-31 11:11 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20100131111012.GM2996@kryten>
With NO_HZ it is useful to know how often the decrementer is going off. The
patch below adds an entry for it and also adds it into the /proc/stat
summaries.
While here, I added performance monitoring and machine check exceptions.
I found it useful to keep an eye on the PMU exception rate
when using the perf tool. Since it's possible to take a completely
handled machine check on a System p box it also sounds like a good idea to
keep a machine check summary.
The event naming matches x86 to keep gratuitous differences to a minimum.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
If people really don't like the x86 short names, we can think up something
else.
Index: linux-cpumask/arch/powerpc/include/asm/hardirq.h
===================================================================
--- linux-cpumask.orig/arch/powerpc/include/asm/hardirq.h 2010-01-30 20:15:07.148462638 +1100
+++ linux-cpumask/arch/powerpc/include/asm/hardirq.h 2010-01-30 21:33:43.160961369 +1100
@@ -6,6 +6,9 @@
typedef struct {
unsigned int __softirq_pending;
+ unsigned int timer_irqs;
+ unsigned int pmu_irqs;
+ unsigned int mce_exceptions;
#if defined(CONFIG_XICS) && defined(CONFIG_SMP)
unsigned long xics_ipi;
#endif
@@ -22,4 +25,10 @@ static inline void ack_bad_irq(unsigned
printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
}
+extern u64 arch_irq_stat_cpu(unsigned int cpu);
+#define arch_irq_stat_cpu arch_irq_stat_cpu
+
+extern u64 arch_irq_stat(void);
+#define arch_irq_stat arch_irq_stat
+
#endif /* _ASM_POWERPC_HARDIRQ_H */
Index: linux-cpumask/arch/powerpc/kernel/time.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/kernel/time.c 2010-01-30 20:15:07.138465242 +1100
+++ linux-cpumask/arch/powerpc/kernel/time.c 2010-01-30 20:15:21.077211379 +1100
@@ -575,6 +575,8 @@ void timer_interrupt(struct pt_regs * re
trace_timer_interrupt_entry(regs);
+ __get_cpu_var(irq_stat).timer_irqs++;
+
/* Ensure a positive value is written to the decrementer, or else
* some CPUs will continuue to take decrementer exceptions */
set_dec(DECREMENTER_MAX);
Index: linux-cpumask/arch/powerpc/kernel/irq.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/kernel/irq.c 2010-01-30 20:15:17.287210745 +1100
+++ linux-cpumask/arch/powerpc/kernel/irq.c 2010-01-30 21:35:54.528460683 +1100
@@ -196,6 +196,21 @@ static int show_other_interrupts(struct
}
#endif /* CONFIG_PPC32 && CONFIG_TAU_INT */
+ seq_printf(p, "%*s: ", prec, "LOC");
+ for_each_online_cpu(j)
+ seq_printf(p, "%10u ", per_cpu(irq_stat, j).timer_irqs);
+ seq_printf(p, " Local timer interrupts\n");
+
+ seq_printf(p, "%*s: ", prec, "CNT");
+ for_each_online_cpu(j)
+ seq_printf(p, "%10u ", per_cpu(irq_stat, j).pmu_irqs);
+ seq_printf(p, " Performance monitoring interrupts\n");
+
+ seq_printf(p, "%*s: ", prec, "MCE");
+ for_each_online_cpu(j)
+ seq_printf(p, "%10u ", per_cpu(irq_stat, j).mce_exceptions);
+ seq_printf(p, " Machine check exceptions\n");
+
seq_printf(p, "%*s: %10u\n", prec, "BAD", ppc_spurious_interrupts);
return 0;
@@ -258,6 +273,26 @@ out:
return 0;
}
+/*
+ * /proc/stat helpers
+ */
+u64 arch_irq_stat_cpu(unsigned int cpu)
+{
+ u64 sum = per_cpu(irq_stat, cpu).timer_irqs;
+
+ sum += per_cpu(irq_stat, cpu).pmu_irqs;
+ sum += per_cpu(irq_stat, cpu).mce_exceptions;
+
+ return sum;
+}
+
+u64 arch_irq_stat(void)
+{
+ u64 sum = ppc_spurious_interrupts;
+
+ return sum;
+}
+
#ifdef CONFIG_HOTPLUG_CPU
void fixup_irqs(cpumask_t map)
{
Index: linux-cpumask/arch/powerpc/kernel/traps.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/kernel/traps.c 2010-01-30 20:15:07.118462038 +1100
+++ linux-cpumask/arch/powerpc/kernel/traps.c 2010-01-30 21:31:57.487211520 +1100
@@ -478,6 +478,8 @@ void machine_check_exception(struct pt_r
{
int recover = 0;
+ __get_cpu_var(irq_stat).mce_exceptions++;
+
/* See if any machine dependent calls. In theory, we would want
* to call the CPU first, and call the ppc_md. one if the CPU
* one returns a positive number. However there is existing code
@@ -960,6 +962,8 @@ void vsx_unavailable_exception(struct pt
void performance_monitor_exception(struct pt_regs *regs)
{
+ __get_cpu_var(irq_stat).pmu_irqs++;
+
perf_irq(regs);
}
^ permalink raw reply
* [PATCH 4/5] powerpc: Convert global "BAD" interrupt to per cpu spurious
From: Anton Blanchard @ 2010-01-31 11:13 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20100131111155.GN2996@kryten>
I often get asked if BAD interrupts are really bad. On some boxes (eg
IBM machines running a hypervisor) there are valid cases where are
presented with an interrupt that is not for us. These cases are common
enough to show up as thousands of BAD interrupts a day.
Tone them down by calling them spurious. Since they can be a significant cause
of OS jitter, we may as well log them per cpu so we know where they are
occurring.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Again, the short name matches x86 but if people are sufficiently confused by
it ("SPU"), then we can think up something else.
Index: linux-cpumask/arch/powerpc/include/asm/hardirq.h
===================================================================
--- linux-cpumask.orig/arch/powerpc/include/asm/hardirq.h 2010-01-30 23:27:24.787211611 +1100
+++ linux-cpumask/arch/powerpc/include/asm/hardirq.h 2010-01-30 23:27:32.277210667 +1100
@@ -9,6 +9,7 @@ typedef struct {
unsigned int timer_irqs;
unsigned int pmu_irqs;
unsigned int mce_exceptions;
+ unsigned int spurious_irqs;
#if defined(CONFIG_XICS) && defined(CONFIG_SMP)
unsigned long xics_ipi;
#endif
@@ -28,7 +29,4 @@ static inline void ack_bad_irq(unsigned
extern u64 arch_irq_stat_cpu(unsigned int cpu);
#define arch_irq_stat_cpu arch_irq_stat_cpu
-extern u64 arch_irq_stat(void);
-#define arch_irq_stat arch_irq_stat
-
#endif /* _ASM_POWERPC_HARDIRQ_H */
Index: linux-cpumask/arch/powerpc/kernel/irq.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/kernel/irq.c 2010-01-30 23:27:24.787211611 +1100
+++ linux-cpumask/arch/powerpc/kernel/irq.c 2010-01-30 23:27:25.080961389 +1100
@@ -77,7 +77,6 @@ DEFINE_PER_CPU_SHARED_ALIGNED(irq_cpusta
EXPORT_PER_CPU_SYMBOL(irq_stat);
int __irq_offset_value;
-static int ppc_spurious_interrupts;
#ifdef CONFIG_PPC32
EXPORT_SYMBOL(__irq_offset_value);
@@ -201,6 +200,11 @@ static int show_other_interrupts(struct
seq_printf(p, "%10u ", per_cpu(irq_stat, j).timer_irqs);
seq_printf(p, " Local timer interrupts\n");
+ seq_printf(p, "%*s: ", prec, "SPU");
+ for_each_online_cpu(j)
+ seq_printf(p, "%10u ", per_cpu(irq_stat, j).spurious_irqs);
+ seq_printf(p, " Spurious interrupts\n");
+
seq_printf(p, "%*s: ", prec, "CNT");
for_each_online_cpu(j)
seq_printf(p, "%10u ", per_cpu(irq_stat, j).pmu_irqs);
@@ -211,8 +215,6 @@ static int show_other_interrupts(struct
seq_printf(p, "%10u ", per_cpu(irq_stat, j).mce_exceptions);
seq_printf(p, " Machine check exceptions\n");
- seq_printf(p, "%*s: %10u\n", prec, "BAD", ppc_spurious_interrupts);
-
return 0;
}
@@ -282,13 +284,7 @@ u64 arch_irq_stat_cpu(unsigned int cpu)
sum += per_cpu(irq_stat, cpu).pmu_irqs;
sum += per_cpu(irq_stat, cpu).mce_exceptions;
-
- return sum;
-}
-
-u64 arch_irq_stat(void)
-{
- u64 sum = ppc_spurious_interrupts;
+ sum += per_cpu(irq_stat, cpu).spurious_irqs;
return sum;
}
@@ -404,8 +400,7 @@ void do_IRQ(struct pt_regs *regs)
if (irq != NO_IRQ && irq != NO_IRQ_IGNORE)
handle_one_irq(irq);
else if (irq != NO_IRQ_IGNORE)
- /* That's not SMP safe ... but who cares ? */
- ppc_spurious_interrupts++;
+ __get_cpu_var(irq_stat).spurious_irqs++;
irq_exit();
set_irq_regs(old_regs);
^ permalink raw reply
* [PATCH 5/5] powerpc: Increase NR_IRQS Kconfig maximum to 32768
From: Anton Blanchard @ 2010-01-31 11:14 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20100131111315.GO2996@kryten>
With dynamic irq descriptors the overhead of a large NR_IRQS is much lower
than it used to be. With more MSI-X capable adapters and drivers exploiting
multiple vectors we may as well allow the user to increase it beyond the
current maximum of 512.
32768 seems large enough that we'd never have to bump it again (although I bet
my prediction is horribly wrong). It boot tests OK and the vmlinux footprint
increase is only around 500kB due to:
struct irq_map_entry irq_map[NR_IRQS];
We format /proc/interrupts correctly with the previous changes:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
286: 0 0 0 0 0 0
516: 0 0 0 0 0 0
16689: 1833 0 0 0 0 0
17157: 0 0 0 0 0 0
17158: 319 0 0 0 0 0
25092: 0 0 0 0 0 0
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-cpumask/arch/powerpc/Kconfig
===================================================================
--- linux-cpumask.orig/arch/powerpc/Kconfig 2010-01-31 15:07:11.707211107 +1100
+++ linux-cpumask/arch/powerpc/Kconfig 2010-01-31 21:52:39.999711689 +1100
@@ -58,7 +58,7 @@ config IRQ_PER_CPU
config NR_IRQS
int "Number of virtual interrupt numbers"
- range 32 512
+ range 32 32768
default "512"
help
This defines the number of virtual interrupt numbers the kernel
^ permalink raw reply
* [PATCH] macintosh/therm_adt746x: Fix sysfs attributes lifetime
From: Jean Delvare @ 2010-01-31 14:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Christian Kujau, Colin Leroy
Looking at drivers/macintosh/therm_adt746x.c, the sysfs files are
created in thermostat_init() and removed in thermostat_exit(), which
are the driver's init and exit functions. These files are backed-up by
a per-device structure, so it looks like the wrong thing to do: the
sysfs files have a lifetime longer than the data structure that is
backing it up.
I think that sysfs files creation should be moved to the end of
probe_thermostat() and sysfs files removal should be moved to the
beginning of remove_thermostat().
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Colin Leroy <colin@colino.net>
Cc: stable@kernel.org
---
drivers/macintosh/therm_adt746x.c | 34 ++++++++++++++++++++++++----------
1 file changed, 24 insertions(+), 10 deletions(-)
--- linux-2.6.33-rc3.orig/drivers/macintosh/therm_adt746x.c 2010-01-06 17:30:48.000000000 +0100
+++ linux-2.6.33-rc3/drivers/macintosh/therm_adt746x.c 2010-01-06 17:36:35.000000000 +0100
@@ -90,6 +90,8 @@ static struct task_struct *thread_therm
static void write_both_fan_speed(struct thermostat *th, int speed);
static void write_fan_speed(struct thermostat *th, int speed, int fan);
+static void thermostat_create_files(void);
+static void thermostat_remove_files(void);
static int
write_reg(struct thermostat* th, int reg, u8 data)
@@ -161,6 +163,8 @@ remove_thermostat(struct i2c_client *cli
struct thermostat *th = i2c_get_clientdata(client);
int i;
+ thermostat_remove_files();
+
if (thread_therm != NULL) {
kthread_stop(thread_therm);
}
@@ -449,6 +453,8 @@ static int probe_thermostat(struct i2c_c
return -ENOMEM;
}
+ thermostat_create_files();
+
return 0;
}
@@ -566,7 +572,6 @@ thermostat_init(void)
struct device_node* np;
const u32 *prop;
int i = 0, offset = 0;
- int err;
np = of_find_node_by_name(NULL, "fan");
if (!np)
@@ -633,6 +638,17 @@ thermostat_init(void)
return -ENODEV;
}
+#ifndef CONFIG_I2C_POWERMAC
+ request_module("i2c-powermac");
+#endif
+
+ return i2c_add_driver(&thermostat_driver);
+}
+
+static void thermostat_create_files(void)
+{
+ int err;
+
err = device_create_file(&of_dev->dev, &dev_attr_sensor1_temperature);
err |= device_create_file(&of_dev->dev, &dev_attr_sensor2_temperature);
err |= device_create_file(&of_dev->dev, &dev_attr_sensor1_limit);
@@ -647,16 +663,9 @@ thermostat_init(void)
if (err)
printk(KERN_WARNING
"Failed to create tempertaure attribute file(s).\n");
-
-#ifndef CONFIG_I2C_POWERMAC
- request_module("i2c-powermac");
-#endif
-
- return i2c_add_driver(&thermostat_driver);
}
-static void __exit
-thermostat_exit(void)
+static void thermostat_remove_files(void)
{
if (of_dev) {
device_remove_file(&of_dev->dev, &dev_attr_sensor1_temperature);
@@ -673,9 +682,14 @@ thermostat_exit(void)
device_remove_file(&of_dev->dev,
&dev_attr_sensor2_fan_speed);
- of_device_unregister(of_dev);
}
+}
+
+static void __exit
+thermostat_exit(void)
+{
i2c_del_driver(&thermostat_driver);
+ of_device_unregister(of_dev);
}
module_init(thermostat_init);
--
Jean Delvare
^ permalink raw reply
* [PATCH] hwmon: (ams) Fix device removal sequence
From: Jean Delvare @ 2010-01-31 14:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Christian Kujau, Stelian Pop, Michael Hanselmann, LM Sensors
Some code that is in ams_exit() (the module exit code) should instead
be called when the device (not module) is removed. It probably doesn't
make much of a difference in the PMU case, but in the I2C case it does
matter.
I make no guarantee that my fix isn't racy, I'm not familiar enough
with the ams driver code to tell for sure.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Christian Kujau <lists@nerdbynature.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Stelian Pop <stelian@popies.net>
Cc: Michael Hanselmann <linux-kernel@hansmi.ch>
Cc: stable@kernel.org
---
Christian tested the I2C variant of the chip, it would be nice if
someone could test the PMU variant too.
drivers/hwmon/ams/ams-core.c | 11 +++++++----
drivers/hwmon/ams/ams-i2c.c | 2 ++
drivers/hwmon/ams/ams-pmu.c | 2 ++
drivers/hwmon/ams/ams.h | 1 +
4 files changed, 12 insertions(+), 4 deletions(-)
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-core.c 2009-06-10 05:05:27.000000000 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-core.c 2010-01-07 17:14:25.000000000 +0100
@@ -213,7 +213,7 @@ int __init ams_init(void)
return -ENODEV;
}
-void ams_exit(void)
+void ams_sensor_detach(void)
{
/* Remove input device */
ams_input_exit();
@@ -221,9 +221,6 @@ void ams_exit(void)
/* Remove attributes */
device_remove_file(&ams_info.of_dev->dev, &dev_attr_current);
- /* Shut down implementation */
- ams_info.exit();
-
/* Flush interrupt worker
*
* We do this after ams_info.exit(), because an interrupt might
@@ -239,6 +236,12 @@ void ams_exit(void)
pmf_unregister_irq_client(&ams_freefall_client);
}
+static void __exit ams_exit(void)
+{
+ /* Shut down implementation */
+ ams_info.exit();
+}
+
MODULE_AUTHOR("Stelian Pop, Michael Hanselmann");
MODULE_DESCRIPTION("Apple Motion Sensor driver");
MODULE_LICENSE("GPL");
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-i2c.c 2009-06-10 05:05:27.000000000 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-i2c.c 2010-01-07 17:12:46.000000000 +0100
@@ -238,6 +238,8 @@ static int ams_i2c_probe(struct i2c_clie
static int ams_i2c_remove(struct i2c_client *client)
{
if (ams_info.has_device) {
+ ams_sensor_detach();
+
/* Disable interrupts */
ams_i2c_set_irq(AMS_IRQ_ALL, 0);
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams-pmu.c 2009-06-10 05:05:27.000000000 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams-pmu.c 2010-01-07 17:13:47.000000000 +0100
@@ -133,6 +133,8 @@ static void ams_pmu_get_xyz(s8 *x, s8 *y
static void ams_pmu_exit(void)
{
+ ams_sensor_detach();
+
/* Disable interrupts */
ams_pmu_set_irq(AMS_IRQ_ALL, 0);
--- linux-2.6.33-rc3.orig/drivers/hwmon/ams/ams.h 2009-06-10 05:05:27.000000000 +0200
+++ linux-2.6.33-rc3/drivers/hwmon/ams/ams.h 2010-01-07 17:11:43.000000000 +0100
@@ -61,6 +61,7 @@ extern struct ams ams_info;
extern void ams_sensors(s8 *x, s8 *y, s8 *z);
extern int ams_sensor_attach(void);
+extern void ams_sensor_detach(void);
extern int ams_pmu_init(struct device_node *np);
extern int ams_i2c_init(struct device_node *np);
--
Jean Delvare
^ permalink raw reply
* [PATCH 00/10] treewide: Fix format strings that misuse continuations
From: Joe Perches @ 2010-01-31 20:02 UTC (permalink / raw)
To: linux-kernel
Cc: alsa-devel, Greg Kroah-Hartman, Christoph Lameter, Takashi Iwai,
Jaroslav Kysela, linux-ide, James E.J. Bottomley, Paul Mackerras,
Sonic Zhang, devel, linux-scsi, linuxppc-dev, Mike Frysinger,
Pekka Enberg, Matt Mackall, Liam Girdwood, linux-mm, netdev,
Mark Brown, uclinux-dist-devel, David S. Miller
Format strings that are continued with \ are frequently misused.
Change them to use mostly single line formats, some longer than 80 chars.
Fix a few miscellaneous typos at the same time.
Joe Perches (10):
arch/powerpc: Fix continuation line formats
arch/blackfin: Fix continuation line formats
drivers/ide: Fix continuation line formats
drivers/serial/bfin_5xx.c: Fix continuation line formats
drivers/scsi/arcmsr: Fix continuation line formats
drivers/staging: Fix continuation line formats
drivers/net/amd8111e.c: Fix continuation line formats
fs/proc/array.c: Fix continuation line formats
mm/slab.c: Fix continuation line formats
sound/soc/blackfin: Fix continuation line formats
arch/blackfin/mach-common/smp.c | 4 +-
arch/powerpc/kernel/nvram_64.c | 6 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c | 8 ++--
arch/powerpc/platforms/pseries/smp.c | 4 +-
drivers/ide/au1xxx-ide.c | 4 +-
drivers/ide/pmac.c | 4 +-
drivers/net/amd8111e.c | 3 +-
drivers/scsi/arcmsr/arcmsr_hba.c | 49 +++++++++----------
drivers/serial/bfin_5xx.c | 6 +--
drivers/staging/dream/qdsp5/audio_mp3.c | 3 +-
.../rtl8187se/ieee80211/ieee80211_softmac_wx.c | 3 +-
drivers/staging/rtl8187se/r8180_core.c | 3 +-
drivers/staging/sep/sep_driver.c | 3 +-
fs/proc/array.c | 7 ++-
mm/slab.c | 4 +-
sound/soc/blackfin/bf5xx-ac97-pcm.c | 8 +--
sound/soc/blackfin/bf5xx-i2s-pcm.c | 3 +-
sound/soc/blackfin/bf5xx-tdm-pcm.c | 3 +-
18 files changed, 55 insertions(+), 70 deletions(-)
^ permalink raw reply
* [PATCH 01/10] arch/powerpc: Fix continuation line formats
From: Joe Perches @ 2010-01-31 20:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <cover.1264967493.git.joe@perches.com>
String constants that are continued on subsequent lines with \
are not good.
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/kernel/nvram_64.c | 6 +++---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 8 ++++----
arch/powerpc/platforms/pseries/smp.c | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index ad461e7..9cf197f 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -338,8 +338,8 @@ static int __init nvram_create_os_partition(void)
rc = nvram_write_header(new_part);
if (rc <= 0) {
- printk(KERN_ERR "nvram_create_os_partition: nvram_write_header \
- failed (%d)\n", rc);
+ printk(KERN_ERR "nvram_create_os_partition: nvram_write_header "
+ "failed (%d)\n", rc);
return rc;
}
@@ -349,7 +349,7 @@ static int __init nvram_create_os_partition(void)
rc = ppc_md.nvram_write((char *)&seq_init, sizeof(seq_init), &tmp_index);
if (rc <= 0) {
printk(KERN_ERR "nvram_create_os_partition: nvram_write "
- "failed (%d)\n", rc);
+ "failed (%d)\n", rc);
return rc;
}
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 6ea4698..a70de10 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -397,12 +397,12 @@ static int parse_cede_parameters(void)
CEDE_LATENCY_PARAM_MAX_LENGTH);
if (call_status != 0)
- printk(KERN_INFO "CEDE_LATENCY: \
- %s %s Error calling get-system-parameter(0x%x)\n",
+ printk(KERN_INFO "CEDE_LATENCY: "
+ "%s %s Error calling get-system-parameter(0x%x)\n",
__FILE__, __func__, call_status);
else
- printk(KERN_INFO "CEDE_LATENCY: \
- get-system-parameter successful.\n");
+ printk(KERN_INFO "CEDE_LATENCY: "
+ "get-system-parameter successful.\n");
return call_status;
}
diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
index b488663..4e7f89a 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -144,8 +144,8 @@ static void __devinit smp_pSeries_kick_cpu(int nr)
hcpuid = get_hard_smp_processor_id(nr);
rc = plpar_hcall_norets(H_PROD, hcpuid);
if (rc != H_SUCCESS)
- printk(KERN_ERR "Error: Prod to wake up processor %d\
- Ret= %ld\n", nr, rc);
+ printk(KERN_ERR "Error: Prod to wake up processor %d "
+ "Ret= %ld\n", nr, rc);
}
}
--
1.6.6.rc0.57.gad7a
^ 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