On 2023-02-11 21:48:56 GMT+01:00, Guenter Roeck wrote: > On 2/11/23 11:48, Leonard Anderweit wrote: >> Am 11.02.23 um 19:54 schrieb Aleksa Savic: >>> On 2023-02-11 19:08:27 GMT+01:00, Guenter Roeck wrote: >>>> >>>> aquaero is already supported, and the checksum is so far generated >>>> and sent. Is it ignored ? Also, is it guaranteed that _all_ aquero devices >>>> don't need it ? >>> >>> Reading its sensors is currently supported, not writing to it (before these >>> patches). >>> >>> The checksum is ignored and not needed for either aquaero 5 (which Leonard has) >>> nor 6 (which I have). >>> >>>> >>>> If it is not needed and ignored, does it really add value to selectively drop it ? >>> >>> I think we can indeed remove that check. >> >> I don't think that check can be removed as the checksum is not appended >> to the control report but is in the last two bytes. So using the >> checksum on Aquaero will overwrite the data at that location. It is >> currently unknown what these two bytes do so I do not want to overwrite >> them. >> > > The current code _does_ overwrite those bytes, or am I missing something ? > > If so, changing that would be a bug fix which really should not be hidden > in a patch making functional changes. > > Thanks, > Guenter The current code indeed does that because the devices that have writing implemented work that way (D5 Next, Quadro, Octo - they have priv->fan_ctrl_offsets set, which is checked in aqc_is_visible()) plus they need the checksum. Regarding the aquaero checksum, I was under the wrong impression that its control report contained a place for it. I've just captured a few reports and it seems to contain purely settings all the way to the end. I've also compared reports before and after making changes and only the changed settings reflected in the hex dumps, showing there really is no checksum. So, to correct myself from earlier: the checksum is not getting ignored; it has no place in it at all, as the code and testing show. Thanks, Aleksa > >>> >>> Thanks, >>> Aleksa >>> >>>> >>>> Either case, this change is not mentioned in the commit log, and it >>>> violates the "one logical change per patch" rule. Please split it into >>>> a separate patch and explain why the change is needed. >>>> >>>> Another change to separate is the introduction of ctrl_report_id >>>> and the secondary_ctrl_report variables, which is also done silently >>>> and not explained. That should also be a separate patch to simplify >>>> review. >> >> I will separate the changes into more commits for the next version. >> >> Regards, >> Leonard >> >>>> >>>> Thanks, >>>> Guenter >>> >
