On Tue, Jan 30, 2018 at 7:17 PM, Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > On Tuesday 30 January 2018 10:59:00 Mario Limonciello wrote: >> There may be race conditions with multiple different functions working >> on a module wide buffer causing one function to get the wrong results. > > Yes, this is better. We really do not need to allocate shared buffer in > dell-laptop anymore. Before this buffer was specially allocated in first > 4GB addresses space because its physical addresses was passed into SMM. +1. >> -static void dell_set_arguments(u32 arg0, u32 arg1, u32 arg2, u32 arg3) >> +static void dell_set_arguments(struct calling_interface_buffer *buffer, >> + u32 arg0, u32 arg1, u32 arg2, u32 arg3) > > Hm... this function has too many parameters :-( > > What about following API? > > static struct calling_interface_buffer dell_set_arguments(u32 arg0, u32 arg1, u32 arg2, u32 arg3); > > It would return filled structure (not a pointer !) I do not think it's a good idea. Either we allocate request on a heap and return a pointer, or we fill the struct with some data on spot. To naming: for allocation: ..._alloc_request() for filling: _fill_request() / _prepare_request() or alike. _set_arguments() not good enough to me. > and caller would be > able to use it as: > > struct calling_interface_buffer buffer; > buffer = dell_set_arguments(0x2, 0, 0, 0); > ret = dell_send_request(&buffer, CLASS_INFO, SELECT_RFKILL); See above. > And maybe after this change, function dell_set_arguments() could have > better name, e.g. dell_prepare_request() (or dell_prepare_request_buffer) > as "set arguments" is not really what would function do (as it return > something). Agree. > > struct calling_interface_buffer buffer; > buffer = dell_prepare_request_buffer(0x2, 0, 0, 0); > ret = dell_send_request(&buffer, CLASS_INFO, SELECT_RFKILL); > > Andy, any suggestion or opinion? See above. -- With Best Regards, Andy Shevchenko
