Skip to content

Make bus substitution optional#11

Open
jonasmalacofilho wants to merge 1 commit into
hramrach:developmentfrom
jonasmalacofilho:fix-scsi-chip-selection
Open

Make bus substitution optional#11
jonasmalacofilho wants to merge 1 commit into
hramrach:developmentfrom
jonasmalacofilho:fix-scsi-chip-selection

Conversation

@jonasmalacofilho

Copy link
Copy Markdown

Hi,

I see that Arch and OpenSUSE are currently using this repository as upstream for lm_sensors.

This is a patch I've made and been using for quite a few years now, that fixes an "Undeclared bus id referenced" issue when trying to specify a HID/SCSI/etc. device in a config file.


From the original PR lm-sensors#371 ("Make bus substitution optional") on the old/previous upstream repository:

Bus substitution is not implemented for most buses for which it is currently required: I²C is supported, but SPI, HID and SCSI are not. Trying to rename the temperature sensor from a specific hard drive with:

chip "drivetemp-scsi-0-0"
label temp1 "Samsung 840 EVO"

currently results in:12

Error: [...]: Undeclared bus id referenced
sensors_init: Can't parse bus name

While bus substitution should still be implemented for these missing buses, it may also be overkill in a lot of scenarios. Like the example above (drivetemp chips), assuming a typical and fairly stable hardware configuration.

To simplify things, make bus substitution optional, and allow users to configure their system directly with bus numbers, even if they might be unstable.

Also note that it is probably more common for multiple hard drives or HID cooling devices of the same model to be present in a system. This means that, in order for bus substitution to be useful for buses like SCSI and HID, it would need to be implemented using unique device identifiers. And not all "serial numbers" reported by devices in the wild are truly unique; in the case of HIDs, manufacturers sometimes omit or repurpose the serial number descriptor.

Footnotes

  1. cannot label 'drivetemp' sensors - bus handling for scsi busted? lm-sensors/lm-sensors#230

  2. (With HID devices:) Undeclared bus id referenced lm-sensors/lm-sensors#369.

Bus substitution is not implemented for most buses for which it is
currently required: I²C is supported, but SPI, HID and SCSI are not.

Trying to rename the temperature sensor from a specific hard drive with:

	chip "drivetemp-scsi-0-0"
	label temp1 "Samsung 840 EVO"

currently results in:

	Error: [...]: Undeclared bus id referenced
	sensors_init: Can't parse bus name

While bus substitution should still be implemented for these missing
buses, it may also be overkill in a lot of scenarios.  Like the example
above (drivetemp chips), assuming a typical and fairly stable hardware
configuration.

To simplify things, make bus substitution optional, and allow users to
configure their system directly with bus numbers, even if they might be
unstable.

Related: lm-sensors#230 ("cannot label 'drivetemp' sensors - bus handling for scsi
busted?")
Related: lm-sensors#369 ("Undeclared bus id referenced")
@hramrach

Copy link
Copy Markdown
Owner

Unfortunately, specifically for SCSI the bus number is very much unstable so long as you have more than one SCSI host.

@jonasmalacofilho

Copy link
Copy Markdown
Author

Do you have any suggestions on how we could handle/improve this?

On the one hand, bailing out as lm-sensors currently does just breaks things even when bus numbers are enough.

On the other, maybe making (the promise that) bus substitution (has become) optional might be a step too far. Maybe we could still report it as an error or unstable feature, just not bail out when substitution isn't implemented for the bus.

I mean, actually implementing substitution for HID, SPI and SCSI would be ideal, but, while it has been a looong time since I looked into it (the original PR was opened on 2021), I vaguely remember it not being an easy problem.

@hramrach

Copy link
Copy Markdown
Owner

Not really. If sensors do not bail out people will complain that their sensors reports something different on every boot.

SPI would likely be fine if only built-in but we now also have USB SPI controllers.

@jonasmalacofilho

jonasmalacofilho commented Apr 21, 2026

Copy link
Copy Markdown
Author

USB is generally quite stable unless you physically connect that the device to a different port, which is not a normal use case for HWMON. Not sure about USB SPI controllers specifically, though.

@jonasmalacofilho

Copy link
Copy Markdown
Author

Hm, I just remembered: I actually rename 4 drive sensors using this patch, and haven't seen their SCSI bus numbers change. I'm not saying they can't change, of course they can, but maybe it isn't as common as you think, at least on some hardware configurations.

On the other hand, is lm_sensors useful today, without this patch, in systems with more than one drive? I mean, other than for displaying the data form drivetemp without any context?

@illwieckz

Copy link
Copy Markdown

What about a command-line option to enable incomplete-but-good-enough implementations like this? Not reporting anything is worse than reporting that drives are too hot.

@kotarou3

Copy link
Copy Markdown

To add another data point about forced bus substitution being detrimental in some cases, on my motherboard with 4 DDR5 channels (config: https://gist.github.com/kotarou3/d2cdf50286b96d45c17e3ea39ac2d673#file-asus-trx50-sage-wifi-sensors-conf-L70-L78)

All 4 sensors are named exactly the same, so it would be impossible to use bus substitution as currently implemented:

$ grep . /sys/bus/i2c/devices/*/name
/sys/bus/i2c/devices/0-0050/name:spd5118
/sys/bus/i2c/devices/0-0052/name:spd5118
/sys/bus/i2c/devices/1-0050/name:spd5118
/sys/bus/i2c/devices/1-0052/name:spd5118

The only way for me to add these sensors is to include this patch so I can match on the bus number directly, which is stable for this board

@hramrach hramrach force-pushed the development branch 3 times, most recently from 8a41efc to 0b5fc76 Compare April 27, 2026 07:53
@hramrach hramrach force-pushed the development branch 3 times, most recently from 3ba5942 to cb9a02a Compare May 25, 2026 07:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants