Oh, I see. Yeah, there isn't way to get it to work in C.I actually struggle to come up with how to do this for the array length+#define TUXI_MAX_FAN_COUNT 16 /* If this is increased, newPlease use static_assert() to actually enforce what the comment says.
lines must
+ * be added to hwmcinfo below.
+ */
because of the macro and the pointer
`static_assert(TUXI_MAX_FAN_COUNT <= ARRAY_SIZE(hwmcinfo[0]->config));`
doesn't work
okkernel.h used to contain way too much of random things. Some people areAdd linux/limits.h include.ack
It is included in kernel.h, so I read from this that kernel.h should not be
used but the parts of it directly?
slowly working towards splitting that up.
So we try to include what is used directly, not rely on includes through
some other include, and especially not through kernel.h.
Yeah my though was: this check is only here to catch the firmware doing some crazy stuff and sending highly unrealistic values, so gifting a small bit of the available range away doesn't matterSo is result of S32_MAX correct when retval is 21474837?No, retval is in 10th of °K (but the last number is always 0) so is+ S32_MAX : (retval - TUXI_FW_TEMP_OFFSET) * 100;Is the math wrong, as you do retval - TUXI_FW_TEMP_OFFSET before
multiplying?
TUXI_FW_TEMP_OFFSET which is there to convert it to 10th of °C, the * 100 is
then to bring it in line with hwmon wanting to output milli degrees
(21474837-2730)*100
2147210700
2^31-1
2147483647
2147210700 would have been representable but the upper bound is
still applied (the value might be large enough to not have practical
significance but to me the code looks still illogical why it applies the
bound prematurely).
I see you already sent another version, it would have been prudent to waitI'm sorry. I just wanted to show that I'm iterating as I wait for the reply if the design with the periodic safeguard is acceptable. If that's gets rejected this driver must be rewritten anyway.
a bit longer as you contested some of the comments so you could have seen
my replies before sending the next version.
So your code relies on implicit type conversion in this: (retval -Shouldn't it be like this:As retval is unsigned this would not work with (theoretical) negative °C.
retval -= TUXI_FW_TEMP_OFFSET;
*val = min(retval * 100, (unsigned long long)S32_MAX);
TUXI_FW_TEMP_OFFSET) ?
Now that I reread things, is this also incorrect, as "i" is at the+ }
+ if (temp >= temp_high)
+ ret = i;
terminator entry at this point?
A function that does read+conversion would be 6-8 lines with the errorbecause here it is with special error handling and didn't thought about an own+Same math issue comment as above.
+ temp = retval > S32_MAX / 100 ?
+ S32_MAX : (retval - TUXI_FW_TEMP_OFFSET) * 100;
Why is the read+conversion code duplicated into two places?
function for a defacto 2 liner
handling.