Re: i2c_powermac: Kernel access of bad area
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
Andrew Morton wrote on 2010/01/30 00:49:24: > > On Thu, 28 Jan 2010 09:52:41 +0100 > Joakim Tjernlund 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: TIF_ABI_PENDING bit removal
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
---
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_PENDING16 /* 32/64 bit switch needed */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1
Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.o
Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
> 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
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(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
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
Re: i2c_powermac: Kernel access of bad area
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 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ping, was Re: [PATCH 1/2] pmac-zilog: add platform driver, version 3
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
