misc: Removal of final callers using fastcall

PATCH In review Harvey Harrison 2 participants 3 messages Dec 12, 2007 – Dec 21, 2007

Subsystems (3)

Memory management PowerPC Page allocator

lore

Share & tools

lore

Harvey Harrison

author

2007-12-12 23:38 UTC #0 lore raw

PATCH 1/1 misc: Removal of final callers using fastcall

fastcall expands to empty everywhere, remove it.

Signed-off-by Harvey Harrison <[email protected]>

---
Andrew, I'm not sure who is best to hit with these final dribs and drabs removing fastcall. Once all of these have hit Linus' tree I will send a final patch deleting the include/linux/linkage.h definitions as well as any remaining occurances.

 arch/powerpc/sysdev/uic.c |    2 +-
 arch/sparc64/kernel/irq.c |    2 +-
 include/asm-arm/mutex.h   |    6 +++---
 mm/page_alloc.c           |    2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

arch/powerpc/sysdev/uic.c +1 -1

index 847a549..bbb6caf 100644
@@ -188,7 +188,7 @@ static struct irq_chip uic_irq_chip = {
  * instead of the end, to keep the window in which we can miss an
  * interrupt as small as possible.
  */
-void fastcall handle_uic_irq(unsigned int irq, struct irq_desc *desc)
+void handle_uic_irq(unsigned int irq, struct irq_desc *desc)
 {
 	unsigned int cpu = smp_processor_id();
 	struct irqaction *action;

arch/sparc64/kernel/irq.c +1 -1

index 30431bd..5ec06c8 100644
@@ -522,7 +522,7 @@ static struct irq_chip sun4v_virq = {
 	.set_affinity	= sun4v_virt_set_affinity,
 };
 
-static void fastcall pre_flow_handler(unsigned int virt_irq,
+static void pre_flow_handler(unsigned int virt_irq,
 				      struct irq_desc *desc)
 {
 	struct irq_handler_data *data = get_irq_chip_data(virt_irq);

include/asm-arm/mutex.h +3 -3

index cb29d84..020bd98 100644
@@ -24,7 +24,7 @@
  * reattempted until it succeeds.
  */
 static inline void
-__mutex_fastpath_lock(atomic_t *count, fastcall void (*fail_fn)(atomic_t *))
+__mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
 {
 	int __ex_flag, __res;

@@ -44,7 +44,7 @@ __mutex_fastpath_lock(atomic_t *count, fastcall void (*fail_fn)(atomic_t *))
 }
 
 static inline int
-__mutex_fastpath_lock_retval(atomic_t *count, fastcall int (*fail_fn)(atomic_t *))
+__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
 {
 	int __ex_flag, __res;

@@ -70,7 +70,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, fastcall int (*fail_fn)(atomic_t *
  * better generated assembly.
  */
 static inline void
-__mutex_fastpath_unlock(atomic_t *count, fastcall void (*fail_fn)(atomic_t *))
+__mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
 {
 	int __ex_flag, __res, __orig;

mm/page_alloc.c +1 -1

index e8206c4..a8b08f9 100644
@@ -1440,7 +1440,7 @@ try_next_zone:
 /*
  * This is the 'heart' of the zoned buddy allocator.
  */
-struct page * fastcall
+struct page *
 __alloc_pages(gfp_t gfp_mask, unsigned int order,
 		struct zonelist *zonelist)
 {

Signature · 1 line

1.5.3.7.2212.gd092

Andrew Morton

maintainer

2007-12-21 02:31 UTC #1 lore raw

Quoted 4 lines · On Wed, 12 Dec 2007 15:38:26 -0800 Harvey Harrison <[email protected]>…

Andrew, I'm not sure who is best to hit with these final dribs and drabs removing fastcall. Once all of these have hit Linus' tree I will send a final patch deleting the include/linux/linkage.h definitions as well as any remaining occurances.

Yes, that's a good approach, thanks. Wait until the tree is fastcall-clean and then kill the definition(s).

I think I skipped rather a lot of remove-fastcall patches because a) suitable maintainers were cc'ed and b) I was going through a suicidal-over-bug-reports phase.

Please keep them coming - I've always disliked fastcall.

Harvey Harrison

author

2007-12-21 06:27 UTC #2 lore raw

Quoted 7 lines · Andrew Morton

Quoted 4 lines · On Wed, 12 Dec 2007 15:38:26 -0800 Harvey Harrison <[email protected]>…
Andrew, I'm not sure who is best to hit with these final dribs and drabs removing fastcall. Once all of these have hit Linus' tree I will send a final patch deleting the include/linux/linkage.h definitions as well as any remaining occurances.

Quoted 8 lines

Yes, that's a good approach, thanks. Wait until the tree is fastcall-clean and then kill the definition(s).
I think I skipped rather a lot of remove-fastcall patches because a) suitable maintainers were cc'ed and b) I was going through a suicidal-over-bug-reports phase.
Please keep them coming - I've always disliked fastcall.

Once I see these have hit the main tree, I'll send patch getting any more that have snuck in for the next rc. After that there should be few enough left that I can send you a small patch for the next rc with the definition removal as well.

I'll keep on top of these.

Harvey