[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.03.1412281540440.18200@gmail.com>
Date: Sun, 28 Dec 2014 15:53:13 +0100 (CET)
From: Enrico Mioso <mrkiko.rs@...il.com>
To: Bjørn Mork <bjorn@...k.no>
cc: "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: refactoring cdc_ncm
Hello everyone, hello Bjorn.
Sorry for my prevous private mail, didn't think about it.
So I was wondering how it could be possible to refactor the cdc_ncm.c driver to
queue frames and only when enough data was collected, generate a full NCM
packet.
so I am trying to get clear what's the way to go.
My idea was to try to not change the layout of the code so much: I would like
not breaking cdc_mbim.c and other code sharing some of these functions, so all
of the work would be done in the cdc_ncm_fill_tx_frame function.
Before starting with code, I would like to organize ideas:
- when an SKB comes in, if the queue isn't empty, I would queue it
Somethink like
if (skb_queue_empty(ctx->skb_tx_queue)){
skb_insert(skb);
} else {
ready2send=1;
}
- at this point, performs some check to see if we have enough data:how can I do
so? What should I check? Sizes of nth16 + ntb16 + ... ?
- if not enough data is present, exit the function returning NULL
else
- invoke some functions to prepare the NCM packet
I plan to move / rewrite the needed code to isolate it completely from the
queue logic: making it also a little bit more clear. I would like to have
separate functions for any parts of the NCM packet construction.
This would allow better flexibility and probably less maintenance burden in the
long run, and might open the road to extending the driver to support 32-bit NCM
and different signness handling.
In the current code, we are carrying around the "sign" variable in the
cdc_ncm_fill_tx_frame: why? Can different NCM packets have different sign
settings?
Thank you guys, waiting for your replies,
Enrico
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists