lm_sensors2/kernel/chips w83792d.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Jean, Dear Mark,

> I second Mark on this, using a loop block when you have no itention to
> actually loop is error-prone.
> 
> It looks quite obvious to me that this block should be made a seperate
> function, as it's quite big and accomplishes a specific task. Breaks
> will become returns, so you would need neither the
> loop-which-is-not-a-loop nor gotos. This is exactly how things are
> supposed to be done in C.

Your suggestion is good, I will adopt it, :-)
I will send you a new patch after my modification and test.

> That's quite logical. I do the same in my pc87360 driver. When the fan
> clock divider is too low and the register overflows, you have no idea
> what the "ideal" divider would be, so you have to increase it step by
> step until you get a valid reading.
> 
> A different approach would be to jump to the highest divider, and go
down
> from there until the register value fits in the ideal range. This
would
> be optimum for missing fans and better for very slow fans, but in the
> common case (fan is present and not too slow), the simple algorithm of
> increasing the divider step by step seems to work better, as the
correct
> divider will be reached after only one or two tries.
> 
> A yet different approach, which I took in the new w83627ehf driver, is
to
> mainly set the divider according to the fan min limit and not to the
fan
> reading. This works because by definition the fan reading should
always
> be more that the limit. That way, users who know which speed they
expect
> will set the limit just below that, which will in turn set the correct
> divider, which will then never change (unless the fan speed actually
> drops below that limit). Or course I always make sure that there is a
> significant room below the limit before a divider change is required.
If
> you think about it, you'll see that it's exactly how voltage channels
> work. Not all voltage values can be measured, only some range around
the
> expected value, typically a 0-133% range of nominal value. Same I do
> with fans in the w83627ehf case.
> 
> These methods are still at the experimental stage, granted, but I
really
> believe that once we have found the best algorithm and implement it in
> more drivers, the end user will enjoy the improvement. Just see how
many
> tickets and posts we have about fan_div problems and you'll see what I
> mean.

Your explanation is as detailed as usual, I can catch it :-)
I will keep my original method (increase/decrease step by step) before
we
find one better method.

Thanks
Best Regards
Chunhao


===========================================================================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original author of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such person, please kindly reply the sender indicating accordingly and delete all copies of it from your computer and network server immediately. We thank you for your cooperation. It is advisable that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email that does not relate to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.===========================================================================================If your computer is unable to decode Chinese font, please ignore the following message. They essentially repea!
 t the  English statement above.???H???????t?????q?l???]???????K?????T, ?????v???o?H?H???w?????H?H???\????. ?????z???D?Q???w?????H?H???]???????]?b???g???v?????????U???????H??, ???z?i?????o?H?H?????Y?N?H???q?q???P???????A???????H????. ?????z???X?@, ?????????P??. ?S??????, ???????g???v?????????????q?l?????K???T???????O?Q?Y???T????. ?H???P?????q?l???~?L???????e,???o?????????q?l?????????N??.



[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux