On Thu, Oct 04, 2018 at 11:19:59AM -0500, Larry Finger wrote: > On 10/4/18 8:42 AM, Stanislaw Gruszka wrote: > >On Thu, Oct 04, 2018 at 03:39:55PM +0300, Kalle Valo wrote: > >>>>Can we put the configuration file in the firmware directory? > >>>>Should we package them into binary files? Or just put the raw data. > >>>> > >>>>We can test the performance for it. After we got the result, we will make a decision > >>>>about it. And if we decide to put them in the firmware directory, will send a patch. > >>>>For now, I think we can just leave them in the .c. > >>> > >>>Yes, you could put the configuration files in the firmware directory. > >>>I would put them in binary form, not as text files. That way the size > >>>would be smaller, and it would not be possible to alter them, > >>>particularly if the binary file is checksummed. > >>> > >>>It would likely be OK if only the agc table was stored in this way. > >>>That would take away about half of the lines in the 8822b table file. > >> > >>So what's the worry here? The lines of source code, binary size or what? > >> > >> .../net/wireless/realtek/rtw88/rtw8822b_table.c | 20783 +++++++++++++++++++ > >> > >>Looking at the diffstat rtw8822b_table.c seems to be 20 kLOC, IMHO it's > >>not that bad as it's just data. But of course I might be missing > >>something as I haven't checked patches yet. > > > >My concern was it's plenty of redundant data, for example: > > > > 0x81C, 0xFF000003, > > 0x81C, 0xFE000003, > > 0x81C, 0xFD020003, > > 0x81C, 0xFC040003, > > 0x81C, 0xFB060003, > > 0x81C, 0xFA080003, > > 0x81C, 0xF90A0003, > > 0x81C, 0xF80C0003, > > 0x81C, 0xF70E0003, > > 0x81C, 0xF6100003, > > > >Approx 10000 lines like this, braked by lines like this > > > > 0x90000012, 0x00000000, 0x40000000, 0x00000000, > > > >in more or less regular way. > > > >Not big deal, but perhaps this could be coded in much more compact way. > > What should be the tradeoff between large tables of redundant data > and complicated generation and interpretation? I think this table > should be converted to binary in its present form and added to the > "firmware", the way that is done for b43. That way the source is > smaller, and the loading will be only a bit more time consuming. If at stake is bigger data and simpler parsing/processing I would take that. But processing is already complex (see RTW_DECL_TABLE* and related functions) and I hope rearranging the data structures could even lead to simplified processing. Thanks Stanislaw
