https://bugzilla.suse.com/show_bug.cgi?id=1231312 https://bugzilla.suse.com/show_bug.cgi?id=1231312#c12 --- Comment #12 from pallas wept <pallaswept@proton.me> --- (In reply to Jean Delvare from comment #9)

Answering some of the concerns listed in the comments, to make things as clear as possible.

Hi Jean, Thanks for your help!

This was extended to AMD-based x86 systems in kernel v6.11.

Hey, that's me :)

Therefore you should NEVER perform automated actions on i2c devices by their i2c bus number.

I certainly wouldn't do that. I mentioned the changing address because, while I'm aware that it has the potential to change, it never has, until this change. I guess, what I was trying to communicate is that it was very clear to me that something unusual had happened to my i2c busses. This doesn't surprise or trouble me now, knowing of the driver changes you've mentioned.

If you are writing to /sys/bus/i2c/devices/i2c-*/new_device to manually instantiate a device, you need to first find the right i2c bus by checking /sys/bus/i2c/devices/i2c-*/name.

I appreciate your warnings, because I do know how bad it could be to send messages to the wrong address - the strange there here is that I'm confident that I didn't. I'm pretty sure *something* did, I've seen what it does, and this looked *exactly* like it (I panicked appropriately). But I followed my own system's build instructions, and literally the first thing they say to do, is to check the address first. I double checked my bash history just now and confirmed that I did check the address first, but I did so by running `sudo i2cdetect -l` - is that sufficient? Maybe this was the error of my ways? Anyway, this was likely why I noticed the changing address - I have the original output of i2cdetect in that document, and the output is different, now. It definitely behaved as if I'd sent the instantiation commands to the GPU's i2c bus, or something similarly terrifying. The memory modules did work via jc42 immediately after the instantiation, and did not, prior to it - I don't know if that's an indication that the address was correct, though? It was only after a subsequent reboot, and during the kernel boot messages, that the monitor started to flash, I immediately powered off, factory reset the monitor and powered it off, powered on again, and only then, it wouldn't even POST, with alternating error codes indicating GPU, PCI and memory failures. Terrifying D:

This i2c bus number instability is clearly inconvenient and this is the very reason why I started working on automating the instantiation of SPD EEPROM a few years ago and upstream is currently working on extending it to more systems and to memory module thermal sensors devices.

Thanks for the work you're putting in! The new features are worth a few teething problems. I'm sure we'll knock this one over :) (In reply to Jean Delvare from comment #10)

How do you "add new [jc42] devices"?

I have a long document with lots of comments but the actual commands and #process: sudo i2cdetect -l # Find the SMBus adapter and query it to make sure the RAM is on it. Example is for i2c-6, which is (still) correct for <=6.10 but>= 6.11, it's always on 1: sudo i2cdetect -y 6 # Confirm the memory by the four sticks in the address ranges 0x18-0x1b and 0x50-0x53 # Instantiate the devices sudo modprobe jc42 echo jc42 0x18 | sudo tee /sys/bus/i2c/devices/i2c-6/new_device echo jc42 0x19 | sudo tee /sys/bus/i2c/devices/i2c-6/new_device echo jc42 0x1a | sudo tee /sys/bus/i2c/devices/i2c-6/new_device echo jc42 0x1b | sudo tee /sys/bus/i2c/devices/i2c-6/new_device I hope that's not too far off the mark? (In reply to Takashi Iwai from comment #11)

FWIW, the *-1 kernel is the reverts of commits: b3e992f69c239b0eb99c408c1ca9cd4253d2e7ad hwmon: (jc42) Strengthen detect function So, if *-1 works for you, it means the jc42 commits that mattered.

I broke the strengthened detect function. That's how strong I am. I'm just that strong. :D I'm sorry. I hope some of this information is useful for you. -- You are receiving this mail because: You are on the CC list for the bug.