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 for your comments. I will keep it as-is for now. Regards, Bing -- 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
