XPost: alt.os.linux.debian, comp.os.linux.hardware, comp.os.linux.setup
XPost: comp.os.linux.x.video
On Saturday January 23 2016 13:07, in alt.os.linux.debian, "Ant" <
ANTant@zimage.com> wrote:
So, no one knows or a way around to make lm_sensors read my old NVIDIA
video card? :(
In comp.os.linux.hardware Ant <ANTant@zimage.com> wrote:
Hello.
I finally upgraded my Debian's oldstable/Wheezy to stable/Jessie last
night. I am having problems with my NVIDIA's sensors that used to work:
$ sudo cat /sys/bus/i2c/devices/i2c-4/new_device
cat: /sys/bus/i2c/devices/i2c-4/new_device: Permission denied
$ ls -all /sys/bus/i2c/devices/i2c-4/new_device
--w------- 1 root root 4096 Dec 27 21:13
/sys/bus/i2c/devices/i2c-4/new_device
/sys/bus/i2c/devices/i2c-4/new_device is write-only for a reason; it is the gateway that a user-space program uses to tell i2c about devices.
,----[
https://www.kernel.org/doc/Documentation/i2c/instantiating-devices]
| In general, the kernel should know which I2C devices are connected and
| what addresses they live at. However, in certain cases, it does not, so a
| sysfs interface was added to let the user provide the information. This
| interface is made of 2 attribute files which are created in every I2C bus
| directory: new_device and delete_device. Both files are write only and you
| must write the right parameters to them in order to properly instantiate,
| respectively delete, an I2C device.
|
| File new_device takes 2 parameters: the name of the I2C device (a string)
| and the address of the I2C device (a number, typically expressed in
| hexadecimal starting with 0x, but can also be expressed in decimal.)
|
| File delete_device takes a single parameter: the address of the I2C
| device. As no two devices can live at the same address on a given I2C
| segment, the address is sufficient to uniquely identify the device to be
| deleted.
|
| Example:
| # echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
|
| While this interface should only be used when in-kernel device declaration
| can't be done, there is a variety of cases where it can be helpful:
| * The I2C driver usually detects devices (method 3 above) but the bus
| segment your device lives on doesn't have the proper class bit set and
| thus detection doesn't trigger.
| * The I2C driver usually detects devices, but your device lives at an
| unexpected address.
| * The I2C driver usually detects devices, but your device is not detected,
| either because the detection routine is too strict, or because your
| device is not officially supported yet but you know it is compatible.
| * You are developing a driver on a test board, where you soldered the I2C
| device yourself.
|
| This interface is a replacement for the force_* module parameters some I2C
| drivers implement. Being implemented in i2c-core rather than in each
| device driver individually, it is much more efficient, and also has the
| advantage that you do not have to reload the driver to change a setting.
| You can also instantiate the device before the driver is loaded or even
| available, and you don't need to know what driver the device needs.
|
`----
How do I make my NVIDIA's sensors command work again in Debian's
Jessie/stable?
Sorry, but I don't know.
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)