Hi Bing, On Wed, Jun 22, 2011 at 11:09, Bing Zhao <bzhao@xxxxxxxxxxx> wrote: > Hi Julian, > >> Also, there are a number of functions touched by this patch that >> return a value through the former *data_buf parameter. Is it possible >> to refactor them to return the value directly? This would make the >> function flow a lot cleaner and easier to follow. > > We have separate parser routines to handle command responses of the commands. In case of GET command we parse the information from response buffer and fill data_buff accordingly. In the patch we submitted, some of the data_buf have been changed to corresponding structure specific to that command. > > Yes, we do have some parser functions that only fill an u16/u32 value in data_buf. But in order to have consistency in the code, we used the data_buf pointers (or specific command struct pointers) for all parser functions. Of course we can change the code to return the value directly for this type of functions, if the consistency is less concerned here. Please let me know your preference on this. I have no preference, and am not aware of any particular general preferences for how such things are handled. If it makes things easier for you, then keep it as it is, it just seemed like a useful cleanup you might want to consider working on in the future. Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
