greybus: manifest: Parse cports (within a bundle) in the order from manifest blob

The order in which cports (of a bundle) are present in the manifest blob
is important for gbsim, as it allocates hd_cport_id's for them
sequentially.

For example, if there are two cports (1 and 2, in order 1->2) present in
a bundle in the manifest blob, then gbsim allocates hd_cport_id X and
X+1 for them. This is done on the assumption that kernel will do the
same. Though it shouldn't have had any such assumptions since the
beginning.

But with a recent patch that sequence is changed, and it broke the
assumption gbsim had.

While parsing the manifest blob, the cports within a bundle are now
moved to another list using list_move() and then they are picked one by
one from the HEAD of the list.

list_move() first deletes the node and then adds it to HEAD as it uses
list_add() and not list_add_tail(). And that reverses the order in which
the cports were present in the original list.

And because of this, the messages destined for cport 1 are delivered to
cport 2 and the ones for cport 2 are delivered to cport 1.

In order to get gbsim working with greybus, keep the cport list in the
order in which they were present in manifest, by replacing list_move()
with list_move_tail().

Its a trivial patch and shouldn't have any side effects on the working
of greybus with nuttx.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/drivers/staging/greybus/manifest.c b/drivers/staging/greybus/manifest.c
index 74e3be997023..070afc619f84 100644
--- a/drivers/staging/greybus/manifest.c
+++ b/drivers/staging/greybus/manifest.c
@@ -263,7 +263,7 @@ static u32 gb_manifest_parse_cports(struct gb_bundle *bundle)
 				goto exit;
 			}
 		}
-		list_move(&desc->links, &list);
+		list_move_tail(&desc->links, &list);
 		count++;
 	}