This is really awesome -- thank you for doing all of this work on the driver.

Out of curiosity--since I no longer have any Apple IR remotes (my last one went away with my AppleTV back in the late 2010s), have you tried taking off the case and looking at the internal chips for identifying marks on any of the ASICs? I'm curious because it might help you figure out which NEC ASIC may or may not be compatible with this driver.

Does building/installing this driver on all platforms (TARGET/TARGET_ARCH) make sense?

Out of curiosity, how much of the Linux driver did you use as a reference for this driver? I'm concerned about licensing of the new code.

I think this should actually be behind another build option.

In D52861#1273156, @obiwac wrote:

In D55635#1273148, @scottl wrote:

The AR_2C_NHI Ids probably came from https://admin.pci-ids.ucw.cz/read/PC/8086/1575. I never had pre-production hardware.

I assume that TR has an ICM, but if you've removed the ICM code from freebsd then that's moot. I would kinda recommend bringing the ICM code back and supporting TR and ICL controllers with it until you've written a comprehensive HCM. Just stay away from AR host controllers.

In D52861#1273135, @scottl wrote:

In D55635#1273085, @obiwac wrote:

One thing I found interesting in this exercise is that the PCI IDs are flip flopped between FreeBSD and Linux: the NHI PCI IDs on FreeBSD are the TB PCIB PCI IDs and vice versa.

Some of these IDs may be wrong (can't find DEVICE_AR_2C_NHI's 0x1575 in the linux code, and I don't know which hardware @scottl was primarily testing), but which ones are flip-flopped? they mostly seem to match to me.

One thing I found interesting in this exercise is that the PCI IDs are flip flopped between FreeBSD and Linux: the NHI PCI IDs on FreeBSD are the TB PCIB PCI IDs and vice versa.

Fix up the PCI ID for DEVICE_TR_2C_NHI (bad-copy paste on my part)

Abandon: this differential received a lot of non-positive feedback. It's best not to push this forward.

I'm sorry -- it's still too early for my brain to be effective at code reviewing. I'll retract my prior acceptance until we get some clarity on some of the changes (most of the changes going from 1->2 look correct, but I'm not sure about some of the edge cases in skip/readin).

Sorry -- forgot to sign-off in my last submission. An answer shouldn't block this change landing since this change should definitely be made (regardless of how it's expressed) as it makes the code more "functionally correct".

Not a huge fan of complexity, but would it make sense to turn these into an enum in a later revision for human readability? I'm game for making the change after you're done if you're busy with other things.

Closing accidental duplicate revision.

Hmm... atopcase(4) still panicked with a similar issue (once I figured out that I needed to add ig4 to my KERNCONF). This may have also occurred because my Mac had low battery and the hardware sends out events on other platforms to suspend the host (there's always a chance that this is a bug with atopcase(4)).

• Re-add drivers that got accidentally removed in the earlier diff.
• Put ufshci back: I mistakingly though the driver was related to USB, but it's not.

I want to give @jkim some time to look at this since the acpi_wmi part of the diff might be unnecessary.

In D55562#1271486, @pho wrote:

In D55562#1271443, @ngie wrote:

My MacBookPro13,1 no longer panics when I run sysctl dev.pci..

@pho : would it make sense to make this a regression test?

There is already a "sysctl -a" scenario that triggers the panic:

root@mercat1:~ # cd /usr/src/tools/test/stress2/misc
root@mercat1:/usr/src/tools/test/stress2/misc # ./sysctl2.sh
panic: acpi_get_flags failed for pci8 on bus pcib8, error = 2

This change fixes the panic for me.

In D55556#1271225, @andrew wrote:

Where is the thunderbolt device defined? I don't see it in main.

Build the .m when acpi/acpi_wmi are explicitly requested. Don't make it
part of the standard kernel.

LGTM. This helped get my MBP13,1 back into a state where it no longer panicked running sysctl dev.pci.

In D55562#1271457, @ngie wrote:

Oddly enough, this may have also fixed some of the sysctl issues with asmc(4) on my MBP13,1 as asmc(4) is an acpi(4) consumer. It was previously complaining about bogus duplicate OIDs, but I figured that was something that I did on the branch, not an issue with acpi(4).
I'll check on my MBP16,1 as well and report back.
CC: @guest-seuros

Oddly enough, this may have also fixed asmc(4) on my MBP13,1 as asmc(4) is an acpi(4) consumer. I'll check on my MBP16,1 as well and report back.

My MacBookPro13,1 no longer panics when I run sysctl dev.pci..

Oof! I'll give this diff a shot on my MBP!

Remove superfluous line added to sys/conf/files.amd64 by accident

Remove the superfluous diff to build netinet/ip_gre.c when INET6 is enabled

Incorporate more touchups to make LINT-NOINET compile/link with gre(4)