In D15891#336482, @kevans wrote:

Please do mention in the commit message that MMCCAM is not usable on Allwinner boards using root-on-MMC to curtail that set of complaints if people actually try it.

Add the comment and this will be sufficient for now.

Seems fine to me.

These all look good. Maybe consider MAINTAINER?= uboot@freebsd.org in the master file?

mechanically, this looks good to me.

I'd reword the commit message.
You are really enabling serial and video early...

I'm leery of committing 'I'm not sure why, but this seems to make it work' kind of code.

Seems good to me...

Are there other disks that we should give this treatment to? Like all of them?

Yes sir! We have a winner!

ref: https://c9x.me/x86/html/file_module_x86_id_139.html
DX is used here, not EDX, for the I/O port giving a range of 0..65,535
Even though you can do 32-bit I/O to a port, the range of the ports is limited to 16-bits.

This is fine.
On x86, the resource I/O port is < 64k. the (void *) is to keep the compiler happy and is a bit of type-punning that the NDIS interface forces upon the user.

this was committed

thanks for doing this largely thankless task.
#ifdef link -= 1000 because of it.

In D15207#334621, @tsoome wrote:

In D15207#334555, @imp wrote:

I don't like this change at all. There's no practical difference, and this diverges us from the normal unix APIs.

there is a problem - zfs is *not* written to use "normal" unix API's. at all. So what we have is the code where unsigned type is swapped to signed and there are virtually no checks against sign wraps, overflows etc. Of course part of the issue is that there is no unsigned off_t and there is always the confusion how many bits that particular type has...

I don't like this change at all. There's no practical difference, and this diverges us from the normal unix APIs.

I think this is good. I'm a little hesitant about the suffix part of it, but know of no good way to flag it's acceptance (I know of several ways, they are all complex and error-prone though).
so, I'd feel better with someone else also blessed the change.

I think this looks good now.

this got lost in my todo inbox. sorry for my delay.

This is somewhat a dangerous change. However, it's the best change we can have given our current use of ofs_bus_status_okay().

try 'camcontrol rescan all'. That's the usual case that breaks locking :(

Generally, I like this path, but I have a couple of questions about locks since I'm having trouble working out the interlock needed.

In D15229#333057, @nwhitehorn wrote:

In D15229#333038, @imp wrote:

The final option would be to do a variation on the prior option, but institutionalize it in DEVICE_ATTACH_LATE. It would be called just after interrupts were enabled for deferred work like this. It would cover the vast majority of driver independencies by giving a 'last' point. At that point, you return an error if you still weren't ready, and we'd loop while the number of devices returning an error was declining. It could largely replace config_intrhook.

I think this would work reasonably well for the general case here; the other suggestions would solve the case of smu(4), but there are other, simpler, ways to do that.

That said, I'm not sure what the advantage of a DEVICE_ATTACH_LATE() is over the mechanism originally proposed here or something like it except that it, as a side effect, delays until after interrupts -- which might not even be wanted, for example if the device in question is an interrupt controller.

The final option would be to do a variation on the prior option, but institutionalize it in DEVICE_ATTACH_LATE. It would be called just after interrupts were enabled for deferred work like this. It would cover the vast majority of driver independencies by giving a 'last' point. At that point, you return an error if you still weren't ready, and we'd loop while the number of devices returning an error was declining. It could largely replace config_intrhook.

Another alternative would be to attach the devices, but defer attaching the children and/or configuring the interrupts until interrupts are enabled. This is another way to ensure doorbell is present and shown in https://reviews.freebsd.org/D15760

An alternative in this case would be https://reviews.freebsd.org/D15759 which defers establishing the interrupt until both devices are present, regardless of the order.

OK. Generally, I really like it.

Do we also need changes to rtld and/or the kernel loader?

This looks good to my eye as far as I can tell...

I'm surprised we need this since I set all CPUs to quiet children if they aren't CPU0.

In D12732#331961, @tsoome wrote:

In D12732#331837, @eric_metricspace.net wrote:

Rebase from master and tried on real hardware

There is one concern - there has been some rework of usb boot images, I think this update should be tested with those new images too, otherwise we risk cutting ourselves..

other than the minor style nits, this looks good.

In D15646#330558, @jtl wrote:

I don't know ISA well. I'm open to switching this to be an option to always panic on any NMI, instead of picking NMI_TIMER2 for special treatment.

In D15592#330397, @ken wrote:

In D15592#330394, @imp wrote:

I like this a lot better. I can't think of any special case I/O we'd need to make an exception on. All the normal commands are what you'd want to block. The abnormal ones are things like FD_FORMAT which will screw things up, but completing the command won't screw them up worse, so that's good. The BIO_ZONE stuff is done via ioctls which won't screw up if we don't complete it. I'd like it if we could allow some clients complete and others be blocked, but that's somewhat beyond the scope.

Keep in mind that although the BIO_ZONE commands are currently done only via ioctl, they are designed to be queued from a filesystem along with other read and write BIOs. So please don't assume that they will always only be called from ioctls; that will change as soon as we have an SMR-capable filesystem.