Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit ea57f80c authored by Dean Nelson's avatar Dean Nelson Committed by Linus Torvalds
Browse files

sgi-xp: eliminate '>>>' in comments 



Comments in /drivers/misc/sgi-xp has been using '>>>' as a means to draw
attention to something that needs to be done or considered.  To avoid
colliding with git rejects, '>>>' will now be replaced by '!!!' to
indicate something to do, and by '???' to indicate something to be
considered.

Signed-off-by: default avatarDean Nelson <dcn@sgi.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent 8e85c23e

drivers/misc/sgi-xp/xp.h

+3 −8
Original line number Diff line number Diff line
@@ -21,7 +21,7 @@ 
#include <asm/sn/arch.h>

#endif



/* >>> Add this #define to some linux header file some day. */

/* ??? Add this #define to some linux header file some day? */

#define BYTES_PER_WORD	sizeof(void *)



#ifdef USE_DBUG_ON
@@ -65,18 +65,13 @@ 
 * other partition that is currently up. Over these channels, kernel-level

 * `users' can communicate with their counterparts on the other partitions.

 *

>>> The following described limitation of a max of eight channels possible

>>> pertains only to ia64-sn2. THIS ISN'T TRUE SINCE I'M PLANNING TO JUST

>>> TIE INTO THE EXISTING MECHANISM ONCE THE CHANNEL MESSAGES ARE RECEIVED.

>>> THE 128-BYTE CACHELINE PERFORMANCE ISSUE IS TIED TO IA64-SN2.

 *

 * If the need for additional channels arises, one can simply increase

 * XPC_MAX_NCHANNELS accordingly. If the day should come where that number

 * exceeds the absolute MAXIMUM number of channels possible (eight), then one

 * will need to make changes to the XPC code to accommodate for this.

 *

 * The absolute maximum number of channels possible is currently limited to

 * eight for performance reasons. The internal cross partition structures

 * The absolute maximum number of channels possible is limited to eight for

 * performance reasons on sn2 hardware. The internal cross partition structures

 * require sixteen bytes per channel, and eight allows all of this

 * interface-shared info to fit in one 128-byte cacheline.

 */

drivers/misc/sgi-xp/xp_sn2.c

+5 −5
Original line number Diff line number Diff line
@@ -87,11 +87,11 @@ xp_remote_memcpy_sn2(void *vdst, const void *psrc, size_t len) 
{

	bte_result_t ret;

	u64 pdst = ia64_tpa(vdst);

	/* >>> What are the rules governing the src and dst addresses passed in?

	 * >>> Currently we're assuming that dst is a virtual address and src

	 * >>> is a physical address, is this appropriate? Can we allow them to

	 * >>> be whatever and we make the change here without damaging the

	 * >>> addresses?

	/* ??? What are the rules governing the src and dst addresses passed in?

	 * ??? Currently we're assuming that dst is a virtual address and src

	 * ??? is a physical address, is this appropriate? Can we allow them to

	 * ??? be whatever and we make the change here without damaging the

	 * ??? addresses?

	 */



	/*

drivers/misc/sgi-xp/xp_uv.c

+1 −1
Original line number Diff line number Diff line
@@ -18,7 +18,7 @@ 
static enum xp_retval

xp_remote_memcpy_uv(void *vdst, const void *psrc, size_t len)

{

	/* >>> this function needs fleshing out */

	/* !!! this function needs fleshing out */

	return xpUnsupported;

}

drivers/misc/sgi-xp/xpc.h

+9 −5
Original line number Diff line number Diff line
@@ -276,9 +276,12 @@ struct xpc_notify { 
 * There is an array of these structures for each remote partition. It is

 * allocated at the time a partition becomes active. The array contains one

 * of these structures for each potential channel connection to that partition.

 */



/*

 * The following is sn2 only.

 *

>>> sn2 only!!!

 * Each of these structures manages two message queues (circular buffers).

 * Each channel structure manages two message queues (circular buffers).

 * They are allocated at the time a channel connection is made. One of

 * these message queues (local_msgqueue) holds the locally created messages

 * that are destined for the remote partition. The other of these message
@@ -345,6 +348,7 @@ struct xpc_notify { 
 *	new messages, by the clearing of the message flags of the acknowledged

 *	messages.

 */



struct xpc_channel_sn2 {



	/* various flavors of local and remote Get/Put values */
@@ -359,7 +363,7 @@ struct xpc_channel_sn2 { 
};



struct xpc_channel_uv {

	/* >>> code is coming */

	/* !!! code is coming */

};



struct xpc_channel {
@@ -500,7 +504,7 @@ xpc_any_msg_chctl_flags_set(union xpc_channel_ctl_flags *chctl) 
}



/*

 * Manages channels on a partition basis. There is one of these structures

 * Manage channels on a partition basis. There is one of these structures

 * for each partition (a partition will never utilize the structure that

 * represents itself).

 */
@@ -535,7 +539,7 @@ struct xpc_partition_sn2 { 
};



struct xpc_partition_uv {

	/* >>> code is coming */

	/* !!! code is coming */

};



struct xpc_partition {

drivers/misc/sgi-xp/xpc_channel.c

+1 −1
Original line number Diff line number Diff line
@@ -129,7 +129,7 @@ xpc_process_disconnect(struct xpc_channel *ch, unsigned long *irq_flags) 


	/* wake those waiting for notify completion */

	if (atomic_read(&ch->n_to_notify) > 0) {

		/* >>> we do callout while holding ch->lock */

		/* we do callout while holding ch->lock, callout can't block */

		xpc_notify_senders_of_disconnect(ch);

	}