Thank you @kib !

In D56291#1287969, @fluffy wrote:

Just reminder: stable/15 is affected too

LGTM too -- thanks!

No ship-blocking items.

A lot of important details are missing from these tests in terms of your thought process in these tests doing what they do, why assertions are being made, etc. These tests aren't really maintainable in their current form longterm.

@imp : you're right -- technically it can be 3.10: https://github.com/bsdimp/ghpr/blob/main/pyproject.toml#L6 .

In D52861#1281083, @obiwac wrote:

If you remove all of the TB3 PCI IDs from the NHI and PCIB drivers, the driver is basically useless for TB3 since it won't probe and attach to anything but generic USB4-capable controllers like the "Pink Sardine" ones (as-is).

Yes, but for the time being it isn't supposed to be useful for other controllers and I do not intend to work on these. I don't want to have code in the tree that I'm not working on, and it really wouldn't be that difficult to add the ICM code later on if someone wants to work on that.

If you could generalize the PCIP_SERIALBUS_USB_USB4 targets vs the Intel TB3 controllers and remove the "Pink Sardine" controllers from the PCI IDs list, I would be totally game for this particular change since it would simplify adding and supporting new drivers (kind of like I did with asmc(4)).
Linux supports per-device quirks for many drivers. We will inevitably likely have to employ similar because of how inconsistent device implementations tend to be with specs.

Yeah, we can do something like in asmc eventually.

It's best to not nerf this code until it really needs to be nerfed, and it would be nice if the ICM code was actually in the tree.

I really disagree with this. I don't want people using code that I have committed, that I have no way of testing myself, and have no intentions of supporting at the moment. I really don't see the issue with someone adding this at a later date if they want to work on it, and I'm glad to help you out if you need to add back the removed logic for this.

I will add a notice in the manpage that this driver explicitly only exists to allow us to suspend USB4 controllers to clear up confusion.

In D55450#1281179, @cperciva wrote:

Personally I would put "move umount /dev into a new function" and "add comments" into different commits, but since you've already done it this way there's no point splitting them apart.

@imp : ping?

@cperciva : ping?

Sort by driver name.

@sunpoet : I'm proposing this update because the issue I ran into in https://github.com/pypa/pipx/issues/1718 is resolved in a newer version of the tool. I don't mind if you take care of the update in ports.
It doesn't look like this port is consumed in-tree, except by sysutils/duplicity .

I'm a bit puzzled... how does this differ from the other revisions?

In D55635#1273248, @obiwac wrote:

In D55635#1273245, @scottl wrote:

What I meant by "kinda recommending" is that if you're going to support TB3 PCI IDs, then bring back the ICM code until you've written an HCM to replace it. Otherwise you're relying on people to find the right option in their BIOS to disable the ICM challenge-response authorization exchange with devices.

Yeah, those should've just been removed in the initial import.

@ngie: is it alright if, for the time being, we get D52861 landed, and then we take another look at resurrecting the ICM code once you've confirmed your and @guest-seuros's hardware can't work with just a HCM?

Move the definition to secure/lib/libcrypto/modules/Makefile.inc

Adjust minimum required python version to 3.11 to match pyproject.toml

In D52861#1273741, @obiwac wrote:

In D52861#1273704, @scottl wrote:

Maybe I’m confused, I was referring to tb_pcib.c.

ah right, yes indeed. Do any of these work without the equivalent NHI support though? I don't have the hardware to test these but my impression was that a connection manager of some sort was necessary to actually configure the bridge to work.

Resolve complaints from portlint

Bump the minimum python3 version to 3.10

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 (some 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 to my prior question/request 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". A code mod switching 0/1/2 to a structured enum, e.g., DIFF_EX_SAME, DIFF_EX_DIFF, DIFF_EX_ERROR can be done at a later point as part of a larger cleanup/code mod.

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.