Winbond 792 source codes for lm_sensor

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

 



Dear Jean:


> > > - Why is the vol_factor array exposed to /proc? Isn't this only
for
> > >   debugging?
> > >   These shouldn't be exposed to the user. If the user needs to
> > >   adjust computation it can be done in /etc/sensors.conf.
> >
> > In the requirements of our customer: the motherboard vendor should
> > have the permission to modify the voltage factor, so I expose it
into
> > /proc. I write it with the reference of our Windows version, the
> > Windows version GUI supply a interface to modify the voltage factor,
> > but it need authentication, That's to say, NOT all of the user can
> > modify it.
> As I understand it, these factors account for the resistors placed on
> the motherboard, which are needed to bring all voltages back into the
> measurable 0V-4V range. Am I correct?

I do NOT know the exact function of factors, maybe you are right, it is
used to bring into some voltage range. I may delete the exposed
interface
vol_factor in /proc later.


> Is so, this does indeed not belong to the driver and has to be
removed.
> Such computation has always been performed in userspace by libsensors,
> for all drivers. The reason for this is that libsensors can do almost
> any mathematical operation, not only apply factors. As a matter of
fact,
> the W83792D chip needs more than factors for -5V and -12V (an
additional
> offset is needed), and unless I am missing something, your driver
> doesn't handle that. There is also a kernel development policy which
> states that conversions should always be moved outside of the kernel
> when possible, and this is exactly what libsensors is there for.
> 
> As a side note, I'm already not certain that restricting the access to
> these values in the Windows world makes sense, but I am certain that
it
> makes no sense in the Linux world. The goal of open-source tools is to
> give the users the possibility to change whatever them want to, and
> certainly not to put restrictions to what they are allowed to do. And
at
> any rate there is no room for such a restriction mechanism in the
> libsensors framework.

In my w83792d.c I calculate the voltages according to the data sheet of
792,
Please refer to the page 39(Chapter 8.6), page 41(Chapter 8.7), page 61
(Chapter 8.28 and 8.29) of 792 Data Sheet.
Do you mean that I should multiply these factors in user space, instead
of
doing that in the driver w83792d.c?
But I find that in the driver w83781d.c, it also do the translation in
kernel
by using such macros:
#define IN_TO_REG(val)  (SENSORS_LIMIT((((val) * 10 + 8)/16),0,255))
#define IN_FROM_REG(val) (((val) * 16 + 5) / 10)

Would you please give me an example on how to move the translate into
user space?
Is it what MDS said:"adjust computation it can be done in
/etc/sensors.conf"


> As a side note, the voltage factors were used in your driver for the
> measured values only, not for the limits (unless I missed something)
so
> it was not working correctly anyway.

Yes, the voltage factors in my driver is only for the measured value,
NOT for the limits, that's because in the Datasheet of 792, the factors
for the measured values are different from for the limits, Please refer
to
the page 39(Chapter 8.6), page 41(Chapter 8.7), page 61 (Chapter 8.28 
and 8.29).

In the driver of w83781d.c I find that the voltage factors are both for
the measured values and the limits. Do you have any suggestions for my
792 driver about it?


> > And I will need your help at that time. For example, to add 792
> > related codes into the script program "sensors-detect" because I
know
> > very few about Perl. :-)
> 
> The sensors-detect script is supposed to already identify the W83792D
> chip (since lm_sensors 2.9.0). If it doesn't, let us know and we'll
fix
> it.
The version of lm_sensors I'm working is 2.9.0. And I find there are
some codes about 792 in script sensors-detect, But it seems that it does
NOT
work, because it can NOT find W83792D chip. Neither do the version 2.8.8
The attachment is the detect result log, you may refer to it and check
the
script again.


> What will obviously require an update though is libsensors. I suppose
> you will provide a patch together with the driver itself? Seems hard
to
> properly test the driver and especially its interaction with "sensors"
> without this.
As to libsensors, I know very few about it, Could you give me a simple
introduction about it? Such as the function of it, and how to update it
for me, etc.


Thanks
Best Regards
Chunhao
2005-1-25



===========================================================================================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 repeat 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??.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: detect_result_log
Type: application/octet-stream
Size: 6311 bytes
Desc: detect_result_log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050125/b73c556d/attachment.obj 


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

  Powered by Linux