Граф коммитов

9 Коммитов

Автор SHA1 Сообщение Дата
Sam Ravnborg a0c54a21dd sparc64: fix sparse warnings in smp_64.c
Fix following warnings:
smp_64.c:88:6: warning: symbol 'smp_callin' was not declared. Should it be static?
smp_64.c:133:6: warning: symbol 'cpu_panic' was not declared. Should it be static?
smp_64.c:187:6: warning: symbol 'smp_synchronize_tick_client' was not declared. Should it be static?
smp_64.c:821:18: warning: symbol 'smp_call_function_client' was not declared. Should it be static?
smp_64.c:827:18: warning: symbol 'smp_call_function_single_client' was not declared. Should it be static?
smp_64.c:964:18: warning: symbol 'smp_new_mmu_context_version_client' was not declared. Should it be static?
smp_64.c:1149:6: warning: symbol 'smp_capture' was not declared. Should it be static?
smp_64.c:1171:6: warning: symbol 'smp_release' was not declared. Should it be static?
smp_64.c:1190:18: warning: symbol 'smp_penguin_jailcell' was not declared. Should it be static?
smp_64.c:1410:18: warning: symbol 'smp_receive_signal_client' was not declared. Should it be static?

Add prototypes in kernel.h or asm/smp_64.h as appropriate.
Delete duplicate function kimage_addr_to_ra(), and
adapt parameter to const void * to match the broader use.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-18 19:01:31 -07:00
David Howells d550bbd40c Disintegrate asm/system.h for Sparc
Disintegrate asm/system.h for Sparc.

Signed-off-by: David Howells <dhowells@redhat.com>
cc: sparclinux@vger.kernel.org
2012-03-28 18:30:03 +01:00
David S. Miller c540ee70e4 sparc64: Delete prom_setcallback().
Unused.

Signed-off-by: David S. Miller <davem@davemloft.net>
2010-11-16 12:50:19 -08:00
David S. Miller f7b5f55ac1 sparc64: Unexport prom_service_exists().
Only used by functions in misc_64.c so make it private
to that file.

Signed-off-by: David S. Miller <davem@davemloft.net>
2010-11-16 12:24:16 -08:00
Andres Salomon 8d1255627d of/sparc: convert various prom_* functions to use phandle
Rather than passing around ints everywhere, use the
phandle type where appropriate for the various functions
that talk to the PROM.

Signed-off-by: Andres Salomon <dilinger@queued.net>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2010-10-09 02:33:34 -06:00
David S. Miller 25edd6946a sparc64: Get rid of indirect p1275 PROM call buffer.
This is based upon a report by Meelis Roos showing that it's possible
that we'll try to fetch a property that is 32K in size with some
devices.  With the current fixed 3K buffer we use for moving data in
and out of the firmware during PROM calls, that simply won't work.

In fact, it will scramble random kernel data during bootup.

The reasoning behind the temporary buffer is entirely historical.  It
used to be the case that we had problems referencing dynamic kernel
memory (including the stack) early in the boot process before we
explicitly told the firwmare to switch us over to the kernel trap
table.

So what we did was always give the firmware buffers that were locked
into the main kernel image.

But we no longer have problems like that, so get rid of all of this
indirect bounce buffering.

Besides fixing Meelis's bug, this also makes the kernel data about 3K
smaller.

It was also discovered during these conversions that the
implementation of prom_retain() was completely wrong, so that was
fixed here as well.  Currently that interface is not in use.

Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-08-23 23:10:57 -07:00
David S. Miller bd4352cadf sparc64: Fix bootup with mcount in some configs.
Functions invoked early when booting up a cpu can't use
tracing because mcount requires a valid 'current_thread_info()'
and TLB mappings to be setup.

The code path of sun4v_register_mondo_queues --> register_one_mondo
is one such case.  sun4v_register_mondo_queues already has the
necessary 'notrace' annotation, but register_one_mondo does not.

Normally register_one_mondo is inlined so the bug doesn't trigger,
but with some config/compiler combinations, it won't be so we
must properly mark it notrace.

While we're here, add 'notrace' annoations to prom_printf and
prom_halt so that early error handling won't have the same problem.

Reported-by: Alexander Beregalov <a.beregalov@gmail.com>
Reported-by: Leif Sawyer <lsawyer@gci.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-09-04 03:39:45 -07:00
Sam Ravnborg 917c3660d6 sparc64: move EXPORT_SYMBOL to the symbols definition
Move all applicable EXPORT_SYMBOL()s to the file where the respective
symbol is defined.

Removed all the includes that are no longer needed in sparc_ksyms_64.c

Comment all remaining EXPORT_SYMBOL()s in sparc_ksyms_64.c

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Additions by Julian Calaby:
* Moved EXPORT_SYMBOL()s for prom functions to their rightful places.
* Made some minor cleanups to the includes and comments of sparc_ksyms_64.c
* Updated and tidied commit message.
* Rebased patch over sparc-2.6.git HEAD.
* Ensured that all modified files have the correct includes.

Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-08 16:58:20 -08:00
Sam Ravnborg 5de18cde3b sparc,sparc64: unify prom/
- all files with identical names copied and renamed to *_64.c
- the remaning files copied as is
- added sparc64 specific files to sparc/prom/Makefile
- teach sparc64 Makefile to look into sparc/prom/
- delete unused Makefile from sparc64/prom/

linking order was not kept for sparc64 with this change.
It was not possible to keep linking order for both sparc and sparc64
and as sparc64 see more testing than sparc it was natural to
break linking order on sparc64. Should it have any effect it
would be detected sooner this way.

printf_32.c and printf_64.c are obvious candidates to be merged
but they are not 100% equal so that was left for later

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-12-04 09:17:17 -08:00