On Sun, Feb 08, 2015 at 11:27:40AM +0100, Sipos Csaba wrote:
Hi,
Good Afternoon,
Will look into this. How can I test if it causes any
problems? I tested the code and it builds without a single warning, but I never used this
end to end python test.
well, you can manually test it by using the online help
(press '?' after a part of the command). If it is empty
then you have a problem.
The same as the first and second answer. A lot of the
alreday provided code is based on the previous bitfield approach for variable handling.
I'd rather not change this on a per variable basis. I consider this a refactor task,
and I don't think my coding skills are up to somethig like this. So if you don't
mind I would stick to this for now, and will try and read a bit about what you suggested,
and get back to this problem later, when I fully understand what needs to be done, and
refactor all variables in the Nokia code to what you have in mind.
> + if(hopping_type != 1){
> + LOGP(DNM, LOGL_NOTICE, "Baseband hopping selected!\n");
> + fu_config[len + 2 + 1] = 1; /* 0: no hopping, 1: Baseband hopping, 2: RF hopping
*/
> + }
> + else
> + {
> + LOGP(DNM, LOGL_NOTICE, "Synthesizer (RF) hopping selected!\n");
> + fu_config[len + 2 + 1] = 2; /* 0: no hopping, 1: Baseband hopping, 2: RF hopping
*/
> + }
I do mind and I am happy to help you to improve the patch. If you use
an enum the above code will turn into
... function (enum nokia_hopping_type hopping_type, ..)
..
fu_config[len + 2 + 1] = hopping_type;
and when you search for the definition of the enum one will read
enum nokia_hopping_type {
Nokia_HoppingNone = 0,
Nokia_HoppingBaseband = 1,
Nokia_HoppingRF = 2,
};
When it comes to code the first priority should be to make it work
and be expressive as possible. E.g. if you use enum's the semantic
is part of the name (I don't need to know that in your case the 0
is mapped to 1 and a 1 mapped to the 2).