This code looks good to me, but I'll defer to others on whether it makes i2c work better for BB. It's been too long for me to green light it, but I think it's OK (but it wouldn't surprise me if there was a 'yea, but what about XXX case' bit of tribal knowledge that we need to not overlook).

I'd be open to making it tunable, but the speed improvements are at beast modest...

I'd be tempted to split this into three: moving the critical section, the math changes and the t_rec -> 2 * t_rec

I'd move the lock to after the if that might do a printf.
Otherwise, this is the right thing to do. We use temp_lock to protect sc->flags only, so this drop doesn't affect that.
In fact, we can go much further than this as noted.
The locking wasn't really attended to when I wrote this driver and I used old-school patterns.

Looks reasonably sane. Saw one magic number. Would like lua implementation, but won't block this based on that.

In D22059#482133, @bdrewery wrote:

In D22059#482035, @imp wrote:

The question is, do we need them to be TARGET_* in this makefile.inc1 usage?
I kinda think it does. Checking into *that* detail...

I had that thought but I don't think so. bsd.compat.mk is included from Makefiles at the point in the build where MACHINE=$TARGET and MACHINE_ARCH=$TARGET_ARCH from CROSSENV. buildlibcompat is a WMAKE_TGT so it should have these MACHINE= and MACHINE_ARCH= values set.

In D22068#482123, @marcel wrote:

Would you mind splitting the changes into 2 reviews/commits. I don't oppose the changes, but they are logically unrelated/independent and it helps us with reversals and/or MFCs if they are separate commits.

The question is, do we need them to be TARGET_* in this makefile.inc1 usage?
I kinda think it does. Checking into *that* detail...

Ah, the missing context makes sense... this is good.

In D22034#481238, @dim wrote:

Hmm, I had explicitly avoided to add any #include statements, due to there being very few of them in this header (it is included by literally everything in libc++). I would rather fix the external toolchains instead, to return the correct version of FreeBSD. But if people feel this is the right way to solve the issue, so be it. But maybe we should not send this upstream.

Generally I like this. I'm unsure of DEV_ACPI stuff is proper...

I didn't see you address Brooks' objection in the posted thread. given the extreme level of exposure here, it needs to be answered satisfactorily

Where was this discussed?

lgtm.. do you have someone to commit this yet?

This seems sane to me...
I'd e tempted to split this into two commits. One for geom_ctl and one for g_nop.

You either want to return success synchronously, or return failure and not change things... so long as there are those semantics, a timeout is fine.

The newbus side of this looks good

Looking giant around bus scan is, sadly, still required. Yea asserts I added :)

Looking at Brooks' ask for llvm90, I think it's not quite ready for prime time, as we fail early in the build:

% make buildworld CROSS_TOOLCHAIN=llvm90 TARGET_ARCH=mips64
...
--- libstdc++.so.6.full ---
building shared library libstdc++.so.6
/usr/local/bin/clang90 -target mips64-unknown-freebsd13.0 --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/mips.mips64/tmp -B/var/empty  -EB -mabi=64 -Wl,--version-script=libstdc++.map    -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o libstdc++.so.6.full -Wl,-soname,libstdc++.so.6  `NM='nm' NMFLAGS='' lorder bitmap_allocator.pico pool_allocator.pico mt_allocator.pico codecvt.pico compatibility.pico complex_io.pico ctype.pico debug.pico debug_list.pico functexcept.pico globals_io.pico ios.pico ios_failure.pico ios_init.pico ios_locale.pico limits.pico list.pico locale.pico locale_init.pico locale_facets.pico localename.pico stdexcept.pico strstream.pico tree.pico allocator-inst.pico concept-inst.pico fstream-inst.pico ext-inst.pico ios-inst.pico iostream-inst.pico istream-inst.pico istream.pico locale-inst.pico misc-inst.pico ostream-inst.pico sstream-inst.pico streambuf-inst.pico streambuf.pico string-inst.pico valarray-inst.pico wlocale-inst.pico wstring-inst.pico atomicity.pico codecvt_members.pico collate_members.pico ctype_members.pico messages_members.pico monetary_members.pico numeric_members.pico time_members.pico basic_file_stdio.pico c_locale.pico atomicity.pico codecvt_members.pico collate_members.pico ctype_members.pico messages_members.pico monetary_members.pico numeric_members.pico time_members.pico basic_file_stdio.pico c_locale.pico stubs.pico del_op.pico del_opnt.pico del_opv.pico del_opvnt.pico eh_alloc.pico eh_arm.pico eh_aux_runtime.pico eh_call.pico eh_catch.pico eh_exception.pico eh_globals.pico eh_personality.pico eh_term_handler.pico eh_terminate.pico eh_throw.pico eh_type.pico eh_unex_handler.pico guard.pico new_handler.pico new_op.pico new_opnt.pico new_opv.pico new_opvnt.pico pure.pico tinfo.pico tinfo2.pico vec.pico vterminate.pico cp-demangle.pico |  tsort -q` -Wl,-f,libsupc++.so.1  -lm
ld: error: can't create dynamic relocation R_MIPS_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output

so I'm going to remain open to making that possible in the future, but won't gate this review on making that work (unless I find a way to make it go).

I'll note it would be nice to have a more generic xtoolchain thing for things like llvm and/or "I'd like to do a universe with all the external toolchains regardless of base compiler support"

xtoolchain part of the IRC ask

On IRC, it was suggested I do the right thing for mips, etc if llvm90 and/or mips-gcc is installed. Will noodle around on that and post an update with riscv moved.

In D16698#478805, @greg_unrelenting.technology wrote:

In D16698#478767, @imp wrote:

So with the suggested changes, I'm not able to get very far with the patches in this review. With wulf's code I'm able to get the device probed. With this code, I see the following

Is this code still really considered? wulf's repo is currently actively developed (now even includes the long-awaited and very necessary "HID bus" abstraction), this was last updated in August.

data point: I'm using wulf's code on my Pixelbook, multi-touch works great for both the touchpad and touchscreen.

So with the suggested changes, I'm not able to get very far with the patches in this review. With wulf's code I'm able to get the device probed. With this code, I see the following:

I'm cool with jhb's reasoning, so this looks ready to land.

I think this is OK. But since it's only /dev that's being mounted here, is the reported problem with aio on raw devices?

In D21886#478100, @nick.hibma_gmail.com wrote:

There is people who expect the first serial device they plug-in to be ttyU0 (me for example) and there are people who would prefer the unit number to stay the same independent of the order the devices are detected (me as well).

I would prefer aliases as well, so we can have both. I didn't check whether it actually is a match to your problem, but how about tty_makealias() in sys/tty.h?

sys/tty.h-int tty_makedevf(struct tty *tp, struct ucred *cred, int flags,
sys/tty.h- const char *fmt, ...) printflike(4, 5);
sys/tty.h-#define TTYMK_CLONING 0x1
sys/tty.h-#define tty_makedev(tp, cred, fmt, ...) \
sys/tty.h- (void )tty_makedevf((tp), (cred), 0, (fmt), __VA_ARGS__) sys/tty.h:#define tty_makealias(tp,fmt,...) \ sys/tty.h- make_dev_alias((tp)->t_dev, fmt, VA_ARGS__)
sys/tty.h-
sys/tty.h-/* Signalling processes. */
sys/tty.h-void tty_signal_sessleader(struct tty *tp, int signal);
sys/tty.h-void tty_signal_pgrp(struct tty *tp, int signal);

I do remember from way back talks about naming schemes for USB devices in the USB device tree, something like usb-1-3-2 being a device plugged into port 2 of a hub that is plugged into port 3 of a hub plugged into port 1 of the root hub.

Unit numbers are kinda lame. Wouldn't it be better to add aliases?

In D21865#477800, @markj wrote:

In D21865#477783, @imp wrote:

I'd propose we kick them out of the tree, put them in ports and let people that care about them be listed as maintainer, or they get deleted from the ports tree...

IMO having drivers in the ports tree doesn't really help. The fact that they're still in ports implies some level of support, so they're still a maintenance burden, and patching out-of-tree code is more work. I would much sooner just build them as modules and keep them in the tree for some time. The out-of-tree legacy DRM drivers are a case in point here.

querying for hptFOO: no controller returns the same number of hits. Spot checking again shows no actual indicated use.

In D21865#477612, @delphij wrote:

+re@

I'm mostly in favor of the change (smaller kernel size, etc.), but since we are removing driver from GENERIC, it's better if we can provide a mechanism to load the driver on demand, or a binary update can easily brick the system...

This has been comitte.d

I thought I'd committed this stuff already...

I've had no requests in the last 4 years since I posted this...

In D20674#476856, @alc wrote:

In D20674#476783, @kib wrote:

In D20674#476657, @alc wrote:

I believe that there is a sound reason for not reporting the unmodified size of the device. Specifically, the swap pager can't use the first, if I recall correctly, 8KB of a swap device because it might contain a disk label. However, I can't explain why we use dmmax to calculate the modified size.

I think reporting the total size minus reserved blocks (for any definition of the block size, correct or not), is more confusing to users than reporting raw size and used. At worst, user would observe that some amount of swap volume is not filled, instead of seeing mismatch between e.g. geom size and vm size for the swap volume.

I'm sympathetic to that argument. In any case, the current code is wrong, in that, it subtracts too much.

That said, I suspect that we no longer need to avoid initial blocks. At least not for the label preservation.

I'm afraid that is not true. I found out the hard way that it is needed. I lost a disk label, swap area, and file system when I first enabled "trimonce". However, the configuration of that storage device is usual. The first partition is a swap area, not a file system.

LGTM

This looks good to me. I'll update the port with it shortly.

In D21697#475800, @arichardson wrote:

If prefer to just spell out the assembly rather than just the magic cp* macros.

In D21733#475782, @ryan_freqlabs.com wrote:

while we've transitioned to teken, it looks like it eats the ESC c

Ok, that looks pretty tough to deal with. Now that you mention it, I'm not seeing colors on the EFI serial console either, and under bhyve the scroll region is broken after the loader hands off to the kernel as well. It's everything I wanted to fix, still broken! Ugh! I thought I had tested that, but I guess I only tested a video output with the EFI console.

I had very similar code in FORTH for our boot loader and it didn't work with EFI, just comconsole. while we've transitioned to teken, it looks like it eats the ESC c and does a reset for the eficonsole, which means that efi's com redirect in the BIOS doesn't work.

Does this work for EFI console? When I tried it, the terminal emualtor intercepted the escape sequences and so the serial console didn't get them...

Do we need this now that tsoome has committed all his stuff to fix the broken color stuff that lead to this situation in the first place?

This looks good to my eye. Don't know if it will work...

This looks good to me.

At least according to https://techpubs.jurassic.nl/manuals/0530/developer/Cplr_PTG/sgi_html/apa.html which appears to be the reproduction of the sgi assembler manual from whence all this stuff came.

How do you know offset 12 on the stack is a good place to store this? I'd expect there to be something like:
cprestore will store gp to <offset>(sp) and then load it from there after every jal operation to restore gp.

I'm struggling to understand here. How does this make it a real option? It seems to say that you must include iflib to get these drivers and there will be no warning if you don't. Maybe I'm misunderstanding something here, but that strikes me as unwise on its surface. I don't think this is a good idea at all, unless I'm missing something.

I'm currently in transit from EuroBSDcon and will likely be out of commission for a couple of days. I'd like to request the favor of getting a chance to review this once I've recovered before you push it in. Thanks!

Seems fine to me. Does this cause an issue for other users of LinuxKPI?

I was going to suggest adding the devmatch changes, but no other ACPI driver seems to have them yet, so I can do that in a sweep.

This looks good to me.

So I think this belongs in share/mk/src.sys.env.mk, but I'm not sure.

If you need more than one sync, then you've broken posix semantics.

Modulo kib's quibble, this is ready to go. No need to repost the review if all you change is the .Dd date and kib's thing.

I wonder why we still have fmtree though

In D21581#470863, @cy wrote:

Does anyone think we need UPDATING or RELNOTES entries? Probably UPDATING. Not sure about RELNOTES.