- 21 10月, 2010 3 次提交
-
-
由 Philippe De Muyter 提交于
In m68k/m68knommu assembly files, the same value is called sometimes PT_OFF_VECTOR, but more frequently PT_OFF_FORMATVEC. Standardize name to PT_OFF_FORMATVEC. Signed-off-by: NPhilippe De Muyter <phdm@macqel.be> Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Philippe De Muyter 提交于
Signed-off-by: NPhilippe De Muyter <phdm@macqel.be> Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
由 Philippe De Muyter 提交于
strace enabled is marked using the `flags' field of the `thread_info' struct. 68360 version of entry.S did test a wrong bit in a wrong structure (task_struct). 68328 version of entry.S did test the right bit in the right structure, but wrongly, because the `flags' field is 32 bit wide, while the used assembler insn (btst) only accesses a 8 bit byte in memory. Fix both using code already used in the coldfire version of entry.S Signed-off-by: NPhilippe De Muyter <phdm@macqel.be> Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
- 30 9月, 2009 1 次提交
-
-
由 Greg Ungerer 提交于
Commit f159ee78 ("locking, m68k/asm-offsets: Rename pt_regs offset defines") breaks the m68knommu entry code that relies on these define names. Fix the files to match the new define names. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
- 20 7月, 2007 1 次提交
-
-
由 Greg Ungerer 提交于
Change the m68knommu irq handling to use the generic irq framework. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 01 7月, 2006 1 次提交
-
-
由 Jörn Engel 提交于
Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 02 9月, 2005 1 次提交
-
-
由 Greg Ungerer 提交于
Use the THREAD_SIZE define when manipulating the stack instead of hard coded values (for the 68328 and 68360 sub-architectures). Signed-off-by: NGreg Ungerer <gerg@uclinux.com> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-