Disappointing that this has been reverted.
The problem that this fixes is now broken again.
It is unlikely that I will be able to debug Franco's problem as I do not have that problem myself. I am also away from my lab for the next several months and do not have equipment with me that I can use to test this situation.
It would be most helpful, Franco, if you could try to debug the code that is supposed to handle the no-autoneg link partner situation.

That would suggest that the lower-level code that is supposed to detect when the link partner does not auto-negotiate and then force the link state up, is not working in your case.

Thanks for your feedback, Eric.

In D16698#452198, @marc.priggemeyer_gmail.com wrote:

I just looked into Microsoft's HID over I2C specification document again. Section 8.2 deals with "Host Initiated Power Optimizations" (HIPO). There, sleep and on are explicitly stated as modes that the host should take care of:
Quote: [1]

The HOST is responsible for optimizing the power of the overall system and the DEVICE. This method of power optimization is to be used when the HOST wishes to provide power optimization notifications to devices.
The following power states are defined for HIPO and are not to be confused with vendor specific DIPO states.

• ON
• SLEEP

Section 7.2.8 specifies the SET_POWER command, so the DEVMETHODs device_suspend and device_resume should implement sleep and wakeup transitions for the human interface device. In addition, the device is not required to respond to the SET_POWER command, so it could be implemented fairly easy. Probably something like this (untested):

static int
iichid_write_register(device_t dev, uint8_t* cmd, int cmdlen)

static int
iichid_set_power(device_t dev, struct i2c_hid_desc* hid_desc, bool sleep)

In D16698#452038, @seanc wrote:

@marc.priggemeyer_gmail.com or @markj, is what's here sufficient for now, or do the edev fixes need to go in, too? It looked like suspend/resume was the biggest issue. I'm worried about this review being a casualty of perfection vs making incremental, usable progress. Given the successes reported so far, I'm trying to gauge what's mandatory vs what should be done next post-commit.

By the way, there is an error in the diff of sys/conf/files in this D16698 patch:

In D16698#448243, @markj wrote:

Could anyone affected by the issue give the patch here a try? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238037

In D16698#448226, @johalun wrote:

I've been playing around with it here https://gist.github.com/johalun/ffc271a07a0cf50d0bc816138c4eec81 but still no success. Basically there are no interrupts from the device after resume. I don't know if this is because ig4 or the i2c device missing some kind of reset command. I found something in MS docs about sending an i2c reset command which you can see in the resume function but it doesn't do anything which makes me think that ig4 is the problem. Here I simply copy/paste the routine from the attach function to resume but not sure that's enough. Probably need to spend some times reading reference manual for the devices.

In D16698#448172, @fbsd_opal.com wrote:

After suspend/resume, all input broken (ims mouse, ums mouse and also keyboard), so need hard reboot to resolve.

In D16698#423707, @justus_sutsuj.com wrote:

Thank you very much Marc. I have been waiting for this and really appreciate your work.

It works almost for me on an ASUS UX310. Sometimes after boot I need to load the iic kernel module and scan the bus using i2c -s -f /dev/iic1.
Furthermore two finger scrolling does not work but it seems to be recognized. At least the cursor does not move during scrolling. The middle mouse button does not work as well.

...