- 27 3月, 2006 1 次提交
-
-
由 Stephen Rothwell 提交于
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 09 1月, 2006 1 次提交
-
-
由 Arnd Bergmann 提交于
/dev/nvram uses the user-provided read/write size for kmalloc, which fails, if a large number is passed. This will always use a single page at most, which can be expected to succeed. Signed-off-by: NArnd Bergmann <arndb@de.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 18 11月, 2005 1 次提交
-
-
由 Paul Mackerras 提交于
This also deletes the now-unused Makefiles under arch/ppc64. Both of the files moved over could use some merging, but for now I have moved them as-is and arranged for them to be used only in 64-bit kernels. For 32-bit kernels we still use arch/ppc/kernel/idle.c and drivers/char/generic_nvram.c as before. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 10 11月, 2005 1 次提交
-
-
由 Paul Mackerras 提交于
This patch merges platform codes. systemcfg->platform is no longer used, systemcfg use in general is deprecated as much as possible (and renamed _systemcfg before it gets completely moved elsewhere in a future patch), _machine is now used on ppc64 along as ppc32. Platform codes aren't gone yet but we are getting a step closer. A bunch of asm code in head[_64].S is also turned into C code. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 28 6月, 2005 1 次提交
-
-
由 Arnd Bergmann 提交于
Convert nvram_create_os_partition to use list_for_each_entry instead of list_for_each, as this reduces the code size by two lines. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 01 5月, 2005 1 次提交
-
-
由 akpm@osdl.org 提交于
- Fix arch/ppc64/kernel/nvram.c:342: warning: `part' might be used uninitialized in this function - Various codingstyle tweaks. Signed-off-by: NAndrew Morton <akpm@osdl.org> 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!
-