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.

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.

@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.

In D20765#449872, @greg_unrelenting.technology wrote:

In D20765#449718, @bcran wrote:

I just tried booting with this patch applied and with EDK2 firmware built from master yesterday, and I still don't see any output - both with devicetree and acpi.

I just tried booting with this patch applied and with EDK2 firmware built from master yesterday, and I still don't see any output - both with devicetree and acpi.

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

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.

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.

...

Tinh Nguyen from Ampere tested and it doesn't seems to make usb working (xhci controller is discovered but nothing more), I've tried on my overdrive in FDT mode and it works.
In acpi mode this doesn't but it doesn't without this patch too, looks like the acpi table is missing info about interrupts, I'll do one more test on the macchiatobin and then commit this.

In D16698#431923, @seanc wrote:

Can someone summarize what's left or preventing this from being committed?

Added fdt detach corresponding to the current attach code (usb-phy)

Driver does not work after resume. I had to reboot to get working touchpad again.

For future updates (to this review, if any, or other reviews) please include context e.g. git diff -U9999

Can someone summarize what's left or preventing this from being committed?

In D19986#431905, @manu wrote:

The fdt needs it's own detach function where we disable the phy (like it's done in D19389 for ehci).

The fdt needs it's own detach function where we disable the phy (like it's done in D19389 for ehci).

As with GregV's report in PR237055 dsdt has for USB:

Method (_STA, 0, NotSerialized)  // _STA: Status
{
    Return (0x00)
}

regardless of BIOS settings; I wasn't able to test this here.

Done. btw, the original version was confirmed working on the Ampere system.

In D19986#430964, @emaste wrote:

In D19986#430466, @manu wrote:

Something like D19389 would be better.

Ah, yes. GregV would you rework it using that approach?

In D19986#430466, @manu wrote:

Something like D19389 would be better.

Something like D19389 would be better.

Patch looks plausible to me, @manu or @andrew can you review and commit?
PR 237055

Please take it.

@hselasky will you commit? Otherwise I can take it.

Here's preliminary evdev support. Can you please incorporate it into your patch?
https://gist.github.com/johalun/3c67a678e740b82512cec52bfe926092

Done. Checked that mlx5ib loads.

mlx5ib depends on ibcore. Can you ensure this module is also built for aarch64 ?

In D19983#429595, @hselasky wrote:

Can you verify that the LINT kernel passes with this change on aarch64?

Can you verify that the LINT kernel passes with this change on aarch64?

Commit message should be something like this:
Enable ioremap for aarch64 in the LinuxKPI.

Sure, split to D19987

Can you split this patch?

Please consider adding it to devd.conf(5) man page.

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

In D13656#422012, @dchagin wrote:

ok, btw, what is the reason to create only 2 devices (eth0 and lo0)?

This is alternate to kqueue EVFILT_FS, but there is no need to keep prev state from getmntinfo() and compare with new to find changes.
Also user can use shell scripts to perform additional actions.

ok, btw, what is the reason to create only 2 devices (eth0 and lo0)?

updated patch to address style(9) issues.

Fixed latest style issue.

What's the motivation for this functionality?

style (9)

Fixed style.

Thanks, LGTM

The updated patch works without a temp file.

The updated patch works without a temp file.

I'm working on adding support for the Intel DesignWare I2C controllers that are connected to my touchpad and my touchscreen, also to the touchpad of another user (who originally requested my help on this issue for his laptop). I think I have a working I2C device(running 'i2c -s -v -f /dev/iic0' kills my working PS/2-connected touchpad). I would like to use your iichid module to instantly add support for these HID devices, but when I build & load iichid I see no new HID device nodes.

Builds on 12.0-STABLE r343501 sources and works fine with Dell Latitude 5590. Thank you!

Updated file path in diff for Phabricator Diffusion browsing